Re: newfs_msdos and DVD-RAM

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