Differences between version 4 and previous revision of FileAllocationTable.
Other diffs: Previous Major Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 4 | Last edited on Monday, August 18, 2003 1:02:14 pm | by JohnMcPherson | Revert |
| Older page: | version 3 | Last edited on Monday, August 18, 2003 6:02:55 am | by AristotlePagaltzis | Revert |
@@ -1,7 +1,9 @@
A FileAllocationTable ([FAT]) is a map maintained by the FileSystem on a HardDisk to keep track of which [DiskCluster]s a file has been stored in. If it spans several of them, they need not be sequential, but rather may be widely scattered over the disk.
+
+[MS-DOS] (and the versions of MicrosoftWindows that sat on top of DOS) used FAT FileSystems... firstly [FAT12], then [FAT16], then [FAT32].
The [FAT] is organized as an array as large as there are clusters on the disk, each entry in the array storing the cluster number of the next piece of a file. This way, the FileSystem driver can "hop" from cluster to cluster, collecting the pieces of the file.
-While simple in concept, a [FAT] is unrealiable
. A single bit error may lead to inconsistencies with several files - they may become crosslinked, with one of the chains pointing to cluster in the other chain. Since allocation of disk space happens in the same step as assigning it to a file, a crash can easily lead to unduly or incompletely allocated space. A crash during rewriting or deleting a file can lead to the a part of the existing chain persisting, without any file pointing to it, thus leaving it inaccessible.
+While simple in concept, a [FAT] is unreliable
. A single bit error may lead to inconsistencies with several files - they may become crosslinked, with one of the chains pointing to cluster in the other chain. [Microsoft] tried to mitigate this by storing a backup version of the table on the partition
. Since allocation of disk space happens in the same step as assigning it to a file, a crash can easily lead to unduly or incompletely allocated space. A crash during rewriting or deleting a file can lead to the a part of the existing chain persisting, without any file pointing to it, thus leaving it inaccessible.
Better FileSystems manage disk space using a separate bitmap for allocation of clusters and [Inode]s for assigning them. The latest in advances are attempts replace all of these with [BTree]s.
