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 must keep compatibility --
period. Can you predict what happen if we try to use some FAT partition
created by Windows (using 512bytes sectors) after we set disk sector
size to 4K? I have feeling that we won't even read partition table
properly, not speaking about FAT. Even GEOM classes supporting big
sector sizes depend on that size to be constant -- otherwise they will
just be unable to locate their own metadata in last sector.
First valid argument, thank you:)
BTW. What Ivan did changes ashift for existing ZFS pools as well, so it
breaks them too.
I can't say anything about it. Ivan told me that it's not. You may
discuss it between yourselves and I'll listen. :)
If we decide to align other things to stripesize we can still break
compatibility with other operating systems.
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 partition to flash sector). Same time for BSD label I see no
problem to align partitions any way we want. I also see no problems to
make FAT cluster, UFS block/fragment, etc, to match some sizes.
Also stripesize is really not good idea. For RAID5 it might be like
64kB or larger, which is definiately too large for ashift in ZFS or
fragment size in UFS.
I agree that minimal I/O size of 64K or 128K may be too much. In this
case I've proposed Ivan to limit maximum used stripesize with some lower
value, possibly tunable. But he preferred to not introduce new constants.
I think we should not depend that stripesize should be small or big or
power-of-2 or anything else. World is not uniform. Even for RAID it can
theoretically vary from 1 sector to half of the disk. We have to
reconsider it each time we are going to use it, taking to account local
limitations and preferences.
--
Alexander Motin
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
