On Tue, 7 Dec 2010, Doug Barton wrote:
On 12/07/2010 03:51, Bruce Cran wrote:
From a new installation of Windows 7 and FreeBSD CURRENT:
GEOM: ada0: partition 3 does not start on a track boundary.
GEOM: ada0: partition 3 does not end on a track boundary.
GEOM: ada0: partition 2 does not start
On 7 December 2010 12:31, Pawel Jakub Dawidek wrote:
> On Tue, Dec 07, 2010 at 12:25:28PM +0100, Ivan Voras wrote:
>> On 7 December 2010 11:21, Pawel Jakub Dawidek wrote:
>>
>> > PS. Do you know your change breaks all current ZFS installation if
>> > stripesize is defined for a provider?
>> >
>>
On 12/07/2010 03:51, Bruce Cran wrote:
On Tue, Dec 07, 2010 at 01:31:27PM +0200, Alexander Motin wrote:
Not necessary. Some places indeed may have some legacy requirements,
for example, in theory MBR want partition to be aligned to "track
boundary" (but I've seen many pre-formatted SD cards with
From: Erik Trulsson
Subject: Re: svn commit: r216230 -
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
Date: Tue, 7 Dec 2010 13:10:58 +0100
> On Tue, Dec 07, 2010 at 01:57:04PM +0200, Andriy Gapon wrote:
> > on 07/12/2010 13:51 Bruce Cran said the following:
> > > On Tue,
From: Bruce Cran
Subject: Re: svn commit: r216230 -
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
Date: Tue, 7 Dec 2010 11:51:06 +
> On Tue, Dec 07, 2010 at 01:31:27PM +0200, Alexander Motin wrote:
> > Not necessary. Some places indeed may have some legacy requirements
on 07/12/2010 14:10 Erik Trulsson said the following:
> On Tue, Dec 07, 2010 at 01:57:04PM +0200, Andriy Gapon wrote:
>> And another reason is that modern drives do not actually report any CHS
>> parameters, so I don't even know where we get them and how we (pretend to)
>> know
>> we track boundar
On Tue, Dec 07, 2010 at 01:57:04PM +0200, Andriy Gapon wrote:
> on 07/12/2010 13:51 Bruce Cran said the following:
> > On Tue, Dec 07, 2010 at 01:31:27PM +0200, Alexander Motin wrote:
> >> Not necessary. Some places indeed may have some legacy requirements,
> >> for example, in theory MBR want part
on 07/12/2010 13:51 Bruce Cran said the following:
> On Tue, Dec 07, 2010 at 01:31:27PM +0200, Alexander Motin wrote:
>> Not necessary. Some places indeed may have some legacy requirements,
>> for example, in theory MBR want partition to be aligned to "track
>> boundary" (but I've seen many pre-for
On Tue, Dec 07, 2010 at 01:31:27PM +0200, Alexander Motin wrote:
> Not necessary. Some places indeed may have some legacy requirements,
> for example, in theory MBR want partition to be aligned to "track
> boundary" (but I've seen many pre-formatted SD cards with MBR
> violating it to align partiti
On Tue, Dec 07, 2010 at 12:25:28PM +0100, Ivan Voras wrote:
> On 7 December 2010 11:21, Pawel Jakub Dawidek wrote:
>
> > PS. Do you know your change breaks all current ZFS installation if
> > stripesize is defined for a provider?
> >
> > # zpool create tank ada0
> > (upgrade FreeBSD
On 07.12.2010 13:04, Pawel Jakub Dawidek wrote:
On Tue, Dec 07, 2010 at 12:25:34PM +0200, Alexander Motin wrote:
It is really nice that we support bigger sector sizes. But unluckily we
are not the only OS in universe. Disks with data may move between
systems, partition could be shared, etc. We m
On 7 December 2010 11:21, Pawel Jakub Dawidek wrote:
> PS. Do you know your change breaks all current ZFS installation if
> stripesize is defined for a provider?
>
> # zpool create tank ada0
> (upgrade FreeBSD so that ada0 now reports 4kB stripesize)
> # zpool import tank
>
On Tue, Dec 07, 2010 at 12:25:34PM +0200, Alexander Motin wrote:
> It is really nice that we support bigger sector sizes. But unluckily we
> are not the only OS in universe. Disks with data may move between
> systems, partition could be shared, etc. We must keep compatibility --
> period. Can you p
On Tue, 7 Dec 2010 10:51:37 +0100
Pawel Jakub Dawidek wrote:
> We can be smarter than that, really. We all know the disk presents 512
> bytes sectors only(?) because most of the software out there
> (including Windows, I guess) will simply break when they see disk
> with 4kB sector.
8 years ago
Pawel Jakub Dawidek wrote:
> On Mon, Dec 06, 2010 at 11:10:38PM +0200, Alexander Motin wrote:
>> On 06.12.2010 22:18, John Baldwin wrote:
>>> On Monday, December 06, 2010 2:53:27 pm Pawel Jakub Dawidek wrote:
On Mon, Dec 06, 2010 at 08:35:36PM +0100, Ivan Voras wrote:
> Please persuade me
On Mon, Dec 06, 2010 at 09:28:42PM +0100, Ivan Voras wrote:
> But there are two reasons that I think are important, which resulted
> in changing this:
>
> 1) It is being used out of the original context in the mailing list
> posts I've referenced - it was being used (and in a worse way, by
> havin
On Mon, Dec 06, 2010 at 11:10:38PM +0200, Alexander Motin wrote:
> On 06.12.2010 22:18, John Baldwin wrote:
> >On Monday, December 06, 2010 2:53:27 pm Pawel Jakub Dawidek wrote:
> >>On Mon, Dec 06, 2010 at 08:35:36PM +0100, Ivan Voras wrote:
> >>>Please persuade me on technical grounds why ashift,
On Mon, Dec 06, 2010 at 03:18:49PM -0500, John Baldwin wrote:
> On Monday, December 06, 2010 2:53:27 pm Pawel Jakub Dawidek wrote:
> > On Mon, Dec 06, 2010 at 08:35:36PM +0100, Ivan Voras wrote:
> > > Please persuade me on technical grounds why ashift, a property
> > > intended for address alignmen
On 6 December 2010 23:36, Andriy Gapon wrote:
> on 07/12/2010 00:00 John Baldwin said the following:
>> It is probably the 4K logical sector size that needs to
>> come up with a new field, not vice versa.
>
> Just expressing my overall confusion - 4K would be the physical size and 512
> would be t
on 07/12/2010 00:00 John Baldwin said the following:
> It is probably the 4K logical sector size that needs to
> come up with a new field, not vice versa.
Just expressing my overall confusion - 4K would be the physical size and 512
would be the logical one? My thinking: on a platter it's a 4K se
On Monday, December 06, 2010 4:22:35 pm Ivan Voras wrote:
> On 6 December 2010 22:16, Bruce Cran wrote:
> > On Mon, Dec 06, 2010 at 09:31:39PM +0100, Ivan Voras wrote:
> >> For what it's worth, apparently linux has the concept of "physical"
> >> and "logical" sector sizes (possibly in addition to
On 06.12.2010 23:22, Ivan Voras wrote:
On 6 December 2010 22:16, Bruce Cran wrote:
On Mon, Dec 06, 2010 at 09:31:39PM +0100, Ivan Voras wrote:
For what it's worth, apparently linux has the concept of "physical"
and "logical" sector sizes (possibly in addition to "stripe size"),
with physical b
On 6 December 2010 22:16, Bruce Cran wrote:
> On Mon, Dec 06, 2010 at 09:31:39PM +0100, Ivan Voras wrote:
>> For what it's worth, apparently linux has the concept of "physical"
>> and "logical" sector sizes (possibly in addition to "stripe size"),
>> with physical being 4096 and logical 512, for e
On Mon, Dec 06, 2010 at 09:31:39PM +0100, Ivan Voras wrote:
> For what it's worth, apparently linux has the concept of "physical"
> and "logical" sector sizes (possibly in addition to "stripe size"),
> with physical being 4096 and logical 512, for example:
>
> # hdparm -I /dev/sde | grep size
> Lo
On 06.12.2010 22:18, John Baldwin wrote:
On Monday, December 06, 2010 2:53:27 pm Pawel Jakub Dawidek wrote:
On Mon, Dec 06, 2010 at 08:35:36PM +0100, Ivan Voras wrote:
Please persuade me on technical grounds why ashift, a property
intended for address alignment, should not be set in this way. I
On 6 December 2010 21:18, John Baldwin wrote:
> On Monday, December 06, 2010 2:53:27 pm Pawel Jakub Dawidek wrote:
>> On Mon, Dec 06, 2010 at 08:35:36PM +0100, Ivan Voras wrote:
>> > Please persuade me on technical grounds why ashift, a property
>> > intended for address alignment, should not be s
Firstly, thank you, your explanations and questions are very good and
address the problems in a good way to discuss about it. I respect that
you took the time to write this answer!
On 6 December 2010 20:53, Pawel Jakub Dawidek wrote:
> On Mon, Dec 06, 2010 at 08:35:36PM +0100, Ivan Voras wrote:
>
On Monday, December 06, 2010 2:53:27 pm Pawel Jakub Dawidek wrote:
> On Mon, Dec 06, 2010 at 08:35:36PM +0100, Ivan Voras wrote:
> > Please persuade me on technical grounds why ashift, a property
> > intended for address alignment, should not be set in this way. If your
> > answer is "I don't know
On Mon, Dec 06, 2010 at 08:35:36PM +0100, Ivan Voras wrote:
> Please persuade me on technical grounds why ashift, a property
> intended for address alignment, should not be set in this way. If your
> answer is "I don't know but you are still wrong because I say so" I
> will respect it and back it o
On 6 December 2010 20:22, Pawel Jakub Dawidek wrote:
> On Mon, Dec 06, 2010 at 07:44:53PM +0100, Pawel Jakub Dawidek wrote:
>> On Mon, Dec 06, 2010 at 12:18:03PM +, Ivan Voras wrote:
>> > Author: ivoras
>> > Date: Mon Dec 6 12:18:02 2010
>> > New Revision: 216230
>> > URL: http://svn.freebsd.
On 6 December 2010 19:44, Pawel Jakub Dawidek wrote:
> On Mon, Dec 06, 2010 at 12:18:03PM +, Ivan Voras wrote:
>> Author: ivoras
>> Date: Mon Dec 6 12:18:02 2010
>> New Revision: 216230
>> URL: http://svn.freebsd.org/changeset/base/216230
>>
>> Log:
>> Use GEOM stripesize field when calcula
On Mon, Dec 06, 2010 at 07:44:53PM +0100, Pawel Jakub Dawidek wrote:
> On Mon, Dec 06, 2010 at 12:18:03PM +, Ivan Voras wrote:
> > Author: ivoras
> > Date: Mon Dec 6 12:18:02 2010
> > New Revision: 216230
> > URL: http://svn.freebsd.org/changeset/base/216230
> >
> > Log:
> > Use GEOM stripe
On Mon, Dec 06, 2010 at 12:18:03PM +, Ivan Voras wrote:
> Author: ivoras
> Date: Mon Dec 6 12:18:02 2010
> New Revision: 216230
> URL: http://svn.freebsd.org/changeset/base/216230
>
> Log:
> Use GEOM stripesize field when calculating ashift. This will enable correct
> alignment on drives
Author: ivoras
Date: Mon Dec 6 12:18:02 2010
New Revision: 216230
URL: http://svn.freebsd.org/changeset/base/216230
Log:
Use GEOM stripesize field when calculating ashift. This will enable correct
alignment on drives with large sector sizes (e.g. 4 KiB) but the
implementation might need to
34 matches
Mail list logo
