Microsoft Extensible Firmware Initiative fat32 File System Specification

struct DSKSZTOSECPERCLUS {

DWORD DiskSize;

BYTE SecPerClusVal;

};

/*

*This is the table for FAT16 drives. NOTE that this table includes

* entries for disk sizes larger than 512 MB even though typically

* only the entries for disks < 512 MB in size are used.

* The way this table is accessed is to look for the first entry

* in the table for which the disk size is less than or equal

* to the DiskSize field in that table entry. For this table to

* work properly BPB_RsvdSecCnt must be 1, BPB_NumFATs

* must be 2, and BPB_RootEntCnt must be 512. Any of these values

* being different may require the first table entries DiskSize value

* to be changed otherwise the cluster count may be to low for FAT16.

*/

DSKSZTOSECPERCLUS DskTableFAT16 [] = {

{ 8400, 0}, /* disks up to 4.1 MB, the 0 value for SecPerClusVal trips an error */

{ 32680, 2}, /* disks up to 16 MB, 1k cluster */

{ 262144, 4}, /* disks up to 128 MB, 2k cluster */

{ 524288, 8}, /* disks up to 256 MB, 4k cluster */

{ 1048576, 16}, /* disks up to 512 MB, 8k cluster */

/* The entries after this point are not used unless FAT16 is forced */

{ 2097152, 32}, /* disks up to 1 GB, 16k cluster */

{ 4194304, 64}, /* disks up to 2 GB, 32k cluster */

{ 0xFFFFFFFF, 0} /* any disk greater than 2GB, 0 value for SecPerClusVal trips an error */

};

/*

* This is the table for FAT32 drives. NOTE that this table includes

* entries for disk sizes smaller than 512 MB even though typically

* only the entries for disks >= 512 MB in size are used.

* The way this table is accessed is to look for the first entry

* in the table for which the disk size is less than or equal

* to the DiskSize field in that table entry. For this table to

* work properly BPB_RsvdSecCnt must be 32, and BPB_NumFATs

* must be 2. Any of these values being different may require the first

* table entries DiskSize value to be changed otherwise the cluster count

* may be to low for FAT32.

*/

DSKSZTOSECPERCLUS DskTableFAT32 [] = {

{ 66600, 0}, /* disks up to 32.5 MB, the 0 value for SecPerClusVal trips an error */

{ 532480, 1}, /* disks up to 260 MB, .5k cluster */

{ 16777216, 8}, /* disks up to 8 GB, 4k cluster */

{ 33554432, 16}, /* disks up to 16 GB, 8k cluster */

{ 67108864, 32}, /* disks up to 32 GB, 16k cluster */

{ 0xFFFFFFFF, 64}/* disks greater than 32GB, 32k cluster */

};

So given a disk size and a FAT type of FAT16 or FAT32, we now have a BPB_SecPerClus value. The only thing we have left is do is to compute how many sectors the FAT takes up so that we can set BPB_FATSz16 or BPB_FATSz32. Note that at this point we assume that BPB_RootEntCnt, BPB_RsvdSecCnt, and BPB_NumFATs are appropriately set. We also assume that DskSize is the size of the volume that we are either going to put in BPB_TotSec32 or BPB_TotSec16.

RootDirSectors = ((BPB_RootEntCnt * 32) + (BPB_BytsPerSec – 1)) / BPB_BytsPerSec;

TmpVal1 = DskSize – (BPB_ResvdSecCnt + RootDirSectors);

TmpVal2 = (256 * BPB_SecPerClus) + BPB_NumFATs;

If(FATType == FAT32)

TmpVal2 = TmpVal2 / 2;

FATSz = (TMPVal1 + (TmpVal2 – 1)) / TmpVal2;

If(FATType == FAT32) {

BPB_FATSz16 = 0;

BPB_FATSz32 = FATSz;

} else {

BPB_FATSz16 = LOWORD(FATSz);

/* there is no BPB_FATSz32 in a FAT16 BPB */

}

Do not spend too much time trying to figure out why this math works. The basis for the computation is complicated; the important point is that this is how Microsoft operating systems do it, and it works. Note, however, that this math does not work perfectly. It will occasionally set a FATSz that is up to 2 sectors too large for FAT16, and occasionally up to 8 sectors too large for FAT32. It will never compute a FATSz value that is too small, however. Because it is OK to have a FATSz that is too large, at the expense of wasting a few sectors, the fact that this computation is surprisingly simple more than makes up for it being off in a safe way in some cases.

FAT32 FSInfo Sector Structure and Backup Boot Sector

On a FAT32 volume, the FAT can be a large data structure, unlike on FAT16 where it is limited to a maximum of 128K worth of sectors and FAT12 where it is limited to a maximum of 6K worth of sectors. For this reason, a provision is made to store the “last known” free cluster count on the FAT32 volume so that it does not have to be computed as soon as an API call is made to ask how much free space there is on the volume (like at the end of a directory listing). The FSInfo sector number is the value in the BPB_FSInfo field; for Microsoft operating systems it is always set to 1. Here is the structure of the FSInfo sector:
FAT32 FSInfo Sector Structure and Backup Boot Sector

Name	Offset (byte)	Size (bytes)	Description
FSI_LeadSig	0	4	Value 0x41615252. This lead signature is used to validate that this is in fact an FSInfo sector.
FSI_Reserved1	4	480	This field is currently reserved for future expansion. FAT32 format code should always initialize all bytes of this field to 0. Bytes in this field must currently never be used.
FSI_StrucSig	484	4	Value 0x61417272. Another signature that is more localized in the sector to the location of the fields that are used.
FSI_Free_Count	488	4	Contains the last known free cluster count on the volume. If the value is 0xFFFFFFFF, then the free count is unknown and must be computed. Any other value can be used, but is not necessarily correct. It should be range checked at least to make sure it is <= volume cluster count.
FSI_Nxt_Free	492	4	This is a hint for the FAT driver. It indicates the cluster number at which the driver should start looking for free clusters. Because a FAT32 FAT is large, it can be rather time consuming if there are a lot of allocated clusters at the start of the FAT and the driver starts looking for a free cluster starting at cluster 2. Typically this value is set to the last cluster number that the driver allocated. If the value is 0xFFFFFFFF, then there is no hint and the driver should start looking at cluster 2. Any other value can be used, but should be checked first to make sure it is a valid cluster number for the volume.
FSI_Reserved2	496	12	This field is currently reserved for future expansion. FAT32 format code should always initialize all bytes of this field to 0. Bytes in this field must currently never be used.
FSI_TrailSig	508	4	Value 0xAA550000. This trail signature is used to validate that this is in fact an FSInfo sector. Note that the high 2 bytes of this value—which go into the bytes at offsets 510 and 511—match the signature bytes used at the same offsets in sector 0.

Another feature on FAT32 volumes that is not present on FAT16/FAT12 is the BPB_BkBootSec field. FAT16/FAT12 volumes can be totally lost if the contents of sector 0 of the volume are overwritten or sector 0 goes bad and cannot be read. This is a “single point of failure” for FAT16 and FAT12 volumes. The BPB_BkBootSec field reduces the severity of this problem for FAT32 volumes, because starting at that sector number on the volume—6—there is a backup copy of the boot sector information including the volume’s BPB.

In the case where the sector 0 information has been accidentally overwritten, all a disk repair utility has to do is restore the boot sector(s) from the backup copy. In the case where sector 0 goes bad, this allows the volume to be mounted so that the user can access data before replacing the disk.
This second case—sector 0 goes bad—is the reason why no value other than 6 should ever be placed in the BPB_BkBootSec field. If sector 0 is unreadable, various operating systems are “hard wired” to check for backup boot sector(s) starting at sector 6 of the FAT32 volume. Note that starting at the BPB_BkBootSec sector is a complete boot record. The Microsoft FAT32 “boot sector” is actually three 512-byte sectors long. There is a copy of all three of these sectors starting at the BPB_BkBootSec sector. A copy of the FSInfo sector is also there, even though the BPB_FSInfo field in this backup boot sector is set to the same value as is stored in the sector 0 BPB.
NOTE: All 3 of these sectors have the 0xAA55 signature in sector offsets 510 and 511, just like the first boot sector does (see the earlier discussion at the end of the BPB structure description).