On Sat, 3 Apr 2010, Tijl Coosemans wrote:
Wikipedia's article on FAT has this to say about the maximum size of
clusters:
"The limit on partition size was dictated by the 8-bit signed count of
sectors per cluster, which had a maximum power-of-two value of 64. With
That seems unlikely. The MS-DOS file system is an old 1970's one meant
for implementation in assembly language on an 8-bit CPU. No assembly
language programmer for an 8-bit microprocessor would expect an 8 bit
or 16 bit counter to be signed, since there aren't enough bits to waste
1 for the sign bit. My reference written in 1986 by an assembly-language
oriented programmer (Duncan) only says that the value must be a power
of 2 though it says that the most other 8-bit variables are BYTEs.
the standard hard disk sector size of 512 bytes, this gives a maximum
of 32 KB clusters, thereby fixing the "definitive" limit for the FAT16
partition size at 2 gigabytes. On magneto-optical media, which can have
1 or 2 KB sectors instead of 1/2 KB, this size limit is proportionally
larger.
However, there was no need to use counts of larger than 1 in 1980, so
support for values of 128 could easily have been broken.
Much later, Windows NT increased the maximum cluster size to 64 KB by
considering the sectors-per-cluster count as unsigned. However, the
resulting format was not compatible with any other FAT implementation
of the time, and it generated greater internal fragmentation. Windows
98 also supported reading and writing this variant, but its disk
utilities did not work with it."
This is demonstably false, since pcfs in FreeBSD-1 was another FAT
implementation of the time (1993), and it is should be missing the bug
since it uses the natural unsigned types for everything in the BPB.
msdosfs in Linux probably provides a better demonstration since it was
of production quality a year or 2 earlier and unlikely to have the bug.
(I don't have its sources handy to check.)
I'm not sure the second paragraph is worth supporting, but the first
seems to say that 32k limit you have in your patch only applies to
disks with 512 byte sectors. For disks with larger sectors it would
be proportionally larger.
It would be interesting to see what breaks with cluster sizes > 64K.
These can be obtained using emulated or physical sector sizes larger
than 512.
Of course you don't want to actually use cluster sizes larger than 4K
(far below 32K) about since they just give portability and fragmentation
losses for tiny or negative performance gains (lose both space and
time to fragmentation). My implementation of clustering for msdosfs
made the cluster sizes unimportant provided it is small enough not to
produce fragmentation, and there is little fragmentation due to other
problems, and there is enough CPU to enblock and deblock the clusters.
Clustering works better for msdosfs than for ffs because there are no
indirect blocks or far-away inode blocks to put bubbles in the i/o
pipeline.
Bruce
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
