Design of the FAT file system


The FAT file system is a file system used on MS-DOS and Windows 9x family of operating systems. It continues to be used on mobile devices and embedded systems, and thus is a well-suited file system for data exchange between computers and devices of almost any type and age from 1981 through to the present.

Structure

A FAT file system is composed of four regions:
RegionSize in sectorsContentsNotes
Reserved sectorsBoot SectorThe first reserved sector is the Boot Sector. It includes an area called the BIOS Parameter Block which contains some basic file system information, in particular its type and pointers to the location of the other sections, and usually contains the operating system's boot loader code.
Important information from the Boot Sector is accessible through an operating system structure called the Drive Parameter Block in DOS and OS/2.
The total count of [|reserved sectors] is indicated by a field inside the Boot Sector, and is usually 32 on FAT32 file systems.
For FAT32 file systems, the reserved sectors include a File System Information Sector at logical [|sector 1] and a Backup Boot Sector at logical sector 6. While many other vendors have continued to utilize a single-sector setup for the bootstrap loader, Microsoft's boot sector code has grown to span over logical sectors [|0] and 2 since the introduction of FAT32, with logical sector 0 depending on sub-routines in logical sector 2. The Backup Boot Sector area consists of three logical sectors 6, 7, and 8 as well. In some cases, Microsoft also uses sector 12 of the reserved sectors area for an extended boot loader.
Reserved sectorsFS Information Sector The first reserved sector is the Boot Sector. It includes an area called the BIOS Parameter Block which contains some basic file system information, in particular its type and pointers to the location of the other sections, and usually contains the operating system's boot loader code.
Important information from the Boot Sector is accessible through an operating system structure called the Drive Parameter Block in DOS and OS/2.
The total count of reserved sectors is indicated by a field inside the Boot Sector, and is usually 32 on FAT32 file systems.
For FAT32 file systems, the reserved sectors include a File System Information Sector at logical sector [|1] and a Backup Boot Sector at logical sector 6. While many other vendors have continued to utilize a single-sector setup for the bootstrap loader, Microsoft's boot sector code has grown to span over logical sectors 0 and 2 since the introduction of FAT32, with logical sector 0 depending on sub-routines in logical sector 2. The Backup Boot Sector area consists of three logical sectors 6, 7, and 8 as well. In some cases, Microsoft also uses sector 12 of the reserved sectors area for an extended boot loader.
Reserved sectorsMore reserved sectors The first reserved sector is the Boot Sector. It includes an area called the BIOS Parameter Block which contains some basic file system information, in particular its type and pointers to the location of the other sections, and usually contains the operating system's boot loader code.
Important information from the Boot Sector is accessible through an operating system structure called the Drive Parameter Block in DOS and OS/2.
The total count of reserved sectors is indicated by a field inside the Boot Sector, and is usually 32 on FAT32 file systems.
For FAT32 file systems, the reserved sectors include a File System Information Sector at logical sector 1 and a Backup Boot Sector at logical sector 6. While many other vendors have continued to utilize a single-sector setup for the bootstrap loader, Microsoft's boot sector code has grown to span over logical sectors 0 and 2 since the introduction of FAT32, with logical sector 0 depending on sub-routines in logical sector 2. The Backup Boot Sector area consists of three logical sectors 6, 7, and 8 as well. In some cases, Microsoft also uses sector 12 of the reserved sectors area for an extended boot loader.
FAT Region * [|File Allocation Table] #1This typically contains two copies of the File Allocation Table for the sake of redundancy checking, although rarely used, even by disk repair utilities. These are maps of the [|Data Region], indicating which clusters are used by files and directories. In FAT12 and FAT16 they immediately follow the reserved sectors. Typically the extra copies are kept in tight synchronization on writes, and on reads they are only used when errors occur in the first FAT. The first two clusters in the map contain special values.
FAT Region * File Allocation Table #2... This typically contains two copies of the File Allocation Table for the sake of redundancy checking, although rarely used, even by disk repair utilities. These are maps of the Data Region, indicating which clusters are used by files and directories. In FAT12 and FAT16 they immediately follow the reserved sectors. Typically the extra copies are kept in tight synchronization on writes, and on reads they are only used when errors occur in the first FAT. The first two clusters in the map contain special values.
Root [|Directory] Region / Root Directory This is a [|Directory Table] that stores information about the files and directories located in the root directory. It is only used with FAT12 and FAT16, and imposes on the root directory a fixed maximum size which is pre-allocated at creation of this volume. FAT32 stores the root directory in the Data Region, along with files and other directories, allowing it to grow without such a constraint. Thus, for FAT32, the Data Region starts here.
Data Region * Data Region ... This is where the actual file and directory data is stored and takes up most of the partition. FAT32 typically commences the Root Directory Table in cluster number 2: the first cluster of the Data Region.

FAT uses little-endian format for all entries in the header and the FAT. It is possible to allocate more FAT sectors than necessary for the number of clusters. The end of the last sector of each FAT copy can be unused if there are no corresponding clusters. The total number of sectors can be larger than the number of sectors used by data, FATs, the root directory, and hidden sectors including the boot sector: this would result in unused sectors at the end of the volume. If a partition contains more sectors than the total number of sectors occupied by the file system it would also result in unused sectors, at the end of the partition, after the volume.

Reserved sectors area

Boot Sector

On non-partitioned storage devices, such as floppy disks, the Boot Sector is the first sector. For partitioned storage devices such as hard disks, the Boot Sector is the first sector of a partition, as specified in the partition table of the device.
Byte offsetLength Contents
0x0003Jump instruction. If the boot sector has a valid signature residing in the [|last two bytes] of the boot sector and this volume is booted from, the prior boot loader will pass execution to this entry point with certain register values, and the jump instruction will then skip past the rest of the header. See Volume Boot Record.
Since DOS 2.0, valid x86-bootable disks must start with either a short jump followed by a NOP or a near jump DOS 2.x formatted disks as well as on some. For backward compatibility MS-DOS, PC DOS and DR-DOS also accept a jump on removable disks. On hard disks, DR DOS additionally accepts the swapped JMPS sequence starting with a NOP, whereas MS-DOS/PC DOS do not. The presence of one of these opstring patterns serves as indicator to DOS 3.3 and higher that some kind of BPB is present, while for DOS 1.x volumes, they will have to fall back to the DOS 1.x method to detect the format via the media byte in the FAT.
0x0038OEM Name. This value determines in which system the disk was formatted.
Although officially documented as free for OEM use, MS-DOS/PC DOS, Windows 95/98/SE/ME and OS/2 check this field to determine which other parts of the boot record can be relied upon and how to interpret them. Therefore, setting the OEM label to arbitrary or bogus values may cause MS-DOS, PC DOS and OS/2 to not recognize the volume properly and cause data corruption on writes. Common examples are "IBM␠␠3.3", "MSDOS5.0", "MSWIN4.1", "IBM␠␠7.1", "mkdosfs␠", and "FreeDOS␠".
Some vendors store licensing info or access keys in this entry.
The Volume Tracker in Windows 95/98/SE/ME will overwrite the OEM label with "?????IHC" signatures even on a seemingly read-only disk access if the medium is not write-protected. Given the dependency on certain values explained above, this may, depending on the actual BPB format and contents, cause MS-DOS/PC DOS and OS/2 to no longer recognize a medium and throw error messages despite the fact that the medium is not defective and can still be read without problems under other operating systems. Windows 9x reads that self-marked disks without any problems but giving some strange values for non-meaning parameters which not exist or are not used when the disk was formatted with older BPB specification, e.g. disk serial number. This applies only to removable disk drives.
Some boot loaders make adjustments or refuse to pass control to a boot sector depending on certain values detected here.
The boot ROM of the Wang Professional Computer will only treat a disk as bootable if the first four characters of the OEM label are "Wang". Similarly, the ROM BIOS of the Philips :YES will only boot from a disk if the first four characters of the OEM label are ":YES".
If, in an FAT32 [|EBPB], the signature at sector offset is and both total sector entries are 0, the file system entry may serve as a 64-bit total sector count entry and the OEM label entry may be used as alternative file system type instead of the normal entry at offset.
In a similar fashion, if this entry is set to "EXFAT␠␠␠", it indicates the usage of an exFAT BPB located at sector offset to, whereas NTFS volumes use "NTFS␠␠␠␠" to indicate an NTFS BPB.
0x00BvariesBIOS Parameter Block, [|Extended BIOS Parameter Block] or FAT32 Extended BIOS Parameter Block ; size and contents varies between operating systems and versions, see below
variesvariesFile system and operating system specific boot code; often starts immediately behind BPB, but sometimes additional "private" boot loader data is stored between the end of the BPB and the start of the boot code; therefore the jump at offset cannot be used to reliably derive the exact BPB format from.
0x1FD1Physical drive number. With OS/2 1.0 and DOS 4.0, this entry moved to sector offset . Most Microsoft and IBM boot sectors maintain values of at offset and ever since, although they are not part of the signature at.
If this belongs to a boot volume, the DR-DOS 7.07 enhanced MBR can be configured to dynamically update this entry to the DL value provided at boot time or the value stored in the partition table. This enables booting off alternative drives, even when the VBR code ignores the DL value.
0x1FE2Boot sector signature. This signature indicates an IBM PC compatible boot code and is tested by most boot loaders residing in the System BIOS or the MBR before passing execution to the boot sector's boot code. This signature does not indicate a particular file system or operating system. Since this signature is not present on all FAT-formatted disks, operating systems must not rely on this signature to be present when logging in volumes. Formatting tools must not write this signature if the written boot sector does not contain at least an x86-compatible dummy boot loader stub; at minimum, it must halt the CPU in an endless loop or issue an INT 19h and RETF. These opstrings should not be used at sector offset, however, because DOS tests for other opcodes as signatures. Many MSX-DOS 2 floppies use at sector offset to catch the CPU in a tight loop while maintaining an opcode pattern recognized by MS-DOS/PC DOS.
This signature must be located at fixed sector offset for sector sizes 512 or higher. If the physical sector size is larger, it may be repeated at the end of the physical sector.
Atari STs will assume a disk to be Atari 68000 bootable if the checksum over the 256 big-endian words of the boot sector equals. If the boot loader code is IBM compatible, it is important to ensure that the checksum over the boot sector does not match this checksum by accident. If this would happen to be the case, changing an unused bit can be used to ensure this condition is not met.
In rare cases, a reversed signature has been observed on disk images. This can be the result of a faulty implementation in the formatting tool based on faulty documentation, but it may also indicate a swapped byte order of the disk image, which might have occurred in transfer between platforms using a different endianness. BPB values and FAT12, FAT16 and FAT32 file systems are meant to use little-endian representation only and there are no known implementations of variants using big-endian values instead.

Byte offsetLength Contents
0x0002Jump instruction. Original Atari ST boot sectors start with a 68000 BRA.S instruction. For compatibility with PC operating systems, Atari ST formatted disks since TOS 1.4 start with instead.
0x0026OEM Name, e.g., "Loader" on volumes containing an Atari ST boot loader. See OEM Name precautions for PC formatted disks above. The offset and length of this entry are different compared to the entry on PC formatted disks.
0x0083Disk serial number, used by Atari ST to detect a disk change. This value must be changed if the disk content is externally changed, otherwise Atari STs may not recognize the change on re-insertion. This entry overlaps the OEM Name field on PC formatted disks. For maximum compatibility, it may be necessary to match certain patterns here; see above.
0x00B19DOS 3.0 BIOS Parameter Block
0x01EvariesPrivate boot sector data
variesvariesFile system and operating system specific Atari ST boot code. No assumptions must be made in regard to the load position of the code, which must be relocatable. If loading an operating system fails, the code can return to the Atari ST BIOS with a 68000 RTS instruction and all registers unaltered.
0x1FE2Checksum. The 16-bit checksum over the 256 big-endian words of the 512 bytes boot sector including this word must match the magic value in order to indicate an Atari ST 68000 executable boot sector code. This checksum entry can be used to align the checksum accordingly.
If the logical sector size is larger than 512 bytes, the remainder is not included in the checksum and is typically zero-filled.
Since some PC operating systems erroneously do not accept FAT formatted floppies if the signature is not present here, it is advisable to place the in this place and use an unused word in the private data or the boot code area or the serial number in order to ensure that the checksum is not matched.

Byte offsetLength Contents
0x0003Dummy jump instruction.
0x0038OEM Name.
0x00B19DOS 3.0 BPB
0x01Evaries MSX-DOS 1 code entry point for Z80 processors into MSX boot code. This is where MSX-DOS 1 machines jump to when passing control to the boot sector. This location overlaps with BPB formats since DOS 3.2 or the x86 compatible boot sector code of IBM PC compatible boot sectors and will lead to a crash on the MSX machine unless special precautions have been taken such as catching the CPU in a tight loop here.
0x0206 MSX-DOS 2 volume signature "VOL_ID".
0x0261MSX-DOS 2 undelete flag.
0x0274MSX-DOS 2 disk serial number. If the "VOL_ID" signature is present at sector offset, MSX-DOS 2 stores a volume serial number here for media change detection.
0x02B5reserved
0x030varies MSX-DOS 2 code entry point for Z80 processors into MSX boot code. This is where MSX-DOS 2 machines jump to when passing control to the boot sector. This location overlaps with EBPB formats since DOS 4.0 / OS/2 1.2 or the x86 compatible boot sector code of IBM PC compatible boot sectors and will lead to a crash on the MSX machine unless special precautions have been taken such as catching the CPU in a tight loop here.
0x1FE2Signature