Penguin
Diff: FileAllocationTable
EditPageHistoryDiffInfoLikePages

Differences between version 4 and revision by previous author of FileAllocationTable.

Other diffs: Previous Major Revision, Previous Revision, 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.