Search code examples
assemblyfilesystemsfat

Why is FAT#2 rarely used?


I read a single-line explanation of FAT#2 from Peter Abel's book IBM PC Assembly Language and Programming.

It says:

Although FAT2 is still maintained, its use has never been implemented.

Wikipedia says:

The FAT Region.

This typically contains two copies (may vary) of the File Allocation Table for the sake of redundancy checking, although rarely used, even by disk repair utilities.

I could think of two strong reasons to use it

  1. All FAT system has one (unless one disables it)
  2. It's built-in

I realize that FAT is a very old file system, but why has FAT#2 never and rarely been implemented?


Solution

  • Assuming "FAT2" means a second copy of the FAT (File Allocation Table) then the basic problem is that it's of little practical use, but I'm not sure if it's true if its actually never used.

    The FAT is a central data structure in the FAT file system, so central that the file system itself is named after it. It's not only a table of which clusters have been allocated or not, it also stores linked lists of the clusters that make up each file. If a single sector in the FAT is damaged, a potentially large number of files could be lost, so someone at some point thought it would be a good idea to have a backup copy of the FAT.

    The problem though is if the FAT is corrupt, how do you tell which copy of the FAT is the correct one? This limits the usefulness of the backup copy to cases when reading from the primary FAT results in read errors. So, at least in theory, if when reading a file the OS encountered an error while reading FAT it could try the backup copy.

    However physical disk errors aren't the only way the FAT could be corrupt. In particular, disk repair utilities, like chkdsk, weren't really designed to fix file system corruption caused by read errors. They were only meant to fix corruption due to bad data being written to the disk. The most common case would be when the computer was shutdown in the middle of writing to the disk. In that case the file system could easily be an inconsistent state. In particular if the OS was in the middle of updating the FAT it might have updated the primary copy but not the backup copy, or it might have updated backup copy but not the primary copy. There's no way to know which.

    I'm not sure if operating systems actually do bother to check the backup FAT after read errors. It's hard to tell, because it rarely makes a difference in practice. Single sector read errors are uncommon on hard disks made in the last 20 years or so, since they remap failing sectors before they go bad. Drives tend to have no disk errors until they fail completely. Even on floppies physical disk errors tend to affect entire tracks, which would wipe out both copies of the FAT.

    Looking at the source for the Linux and FreeBSD FAT file system implementations it appears neither tries the backup FAT if reading from the primary FAT fails. I don't know what any of Microsoft's three main implementations (MS-DOS, Windows 95 or Windows NT) do.