fat32: FAT is two entries too small at certain filesystem sizes

[eriknordmark]

Summary

For certain filesystem sizes, fat32.Create lays out a FAT that is exactly two entries too small for the cluster count it declares. The two highest clusters have no FAT entries, so the resulting filesystem is malformed and fsck.vfat rejects it:

Filesystem has 129024 clusters but only space for 129022 FAT entries.

The size has to be just right for this to happen, so most filesystems come out fine — but the affected sizes include round numbers such as 64 MiB and 4 GiB.

Reproduction

d, _ := diskfs.Create("fs.img", 64*1024*1024, 512)
d.CreateFilesystem(disk.FilesystemSpec{Partition: 0, FSType: filesystem.TypeFat32})
d.Close()

$ fsck.vfat -n fs.img
Filesystem has 129024 clusters but only space for 129022 FAT entries.
$ echo $?
1

Verified on master (c5b3b50) with fsck.fat 4.2. 63 MiB and 65 MiB are clean; 64 MiB is not.

Root cause

filesystem/fat32/fat32.go:131-136:

totalSectors := uint32(size / blocksize)
// Closed-form equivalent of the dosfstools mkfs.fat sectors-per-FAT search:
// smallest X such that (reserved + 2X + clusters*SPC) == totalSectors and
// X * (bytesPerSector/4) >= clusters + 2.
fatEntryDenom := uint32(blocksize)*uint32(sectorsPerCluster) + 8
sectorsPerFat := uint16((4*(totalSectors-uint32(reservedSectors)) + fatEntryDenom - 1) / fatEntryDenom)

Solving the two conditions stated in the comment for X gives

X = 4*(totalSectors - reservedSectors + 2*SPC) / (bytesPerSector*SPC + 8)

The numerator in the code omits the + 2*SPC term, which is the contribution of the + 2 in clusters + 2 — FAT entries 0 and 1 are reserved and cannot describe clusters. Usually the + fatEntryDenom - 1 rounding up absorbs the shortfall, but when the division comes out exact it does not, and the FAT ends up one sector short.

At 64 MiB with 512-byte sectors: 4*(131072-32)/520 = 1008.0 exactly, so sectorsPerFat is 1008, giving 129024 clusters and a FAT holding 129024 entries — of which only 129022 can name a cluster.

Affected sizes

Modelling the formula over 16 MiB–4 GiB at both supported sector sizes, 48 of 8162 sizes produce a FAT too small by two entries, among them:

size	sector size	clusters	FAT entries
64 MiB	512	129024	129024
129 MiB	512	260096	260096
259 MiB	512	522240	522240
449 MiB	4096	114688	114688
4096 MiB	512	1046528	1046528

fsck.vfat confirms the predicted failures at 64, 129, 259 and 4096 MiB, and confirms the neighbouring sizes (63, 65, 128, 130 MiB) are clean.

Proposed fix

Add the missing term to the numerator:

sectorsPerFat := uint16((4*(totalSectors-uint32(reservedSectors)) + 8*uint32(sectorsPerCluster) +
    fatEntryDenom - 1) / fatEntryDenom)

With that change all 8162 modelled sizes satisfy sectorsPerFat*bytesPerSector/4 >= clusterCount+2, and no size that is currently correct changes to an invalid layout (the ones that move gain a single FAT sector and lose two clusters — e.g. 64 MiB becomes 1009 sectors per FAT, 129022 clusters, 129152 entries).

Worth guarding with a test that asserts that invariant across a range of sizes and both sector sizes, since the failing sizes are sparse and easy to miss by sampling.