Mail Archives: djgpp/1997/09/11/16:44:13
On 7 Sep 1997, Paul Derbyshire wrote:
>
> Victor Escobar (sydbarrett AT mindspring DOT com) writes:
> > You mean FAT32? It's OK. But still nothing compared to a decent Unix
> > file system. It has all the shortcomings of FAT16 and is 5-10% slower
> > (at least in the beta version). As for running DOS stuff under
> > Windows98, I've noticed on my build that the DOS prompt is very
> > unstable.
>
> On the other hand I can't think what the alternative could be. Perhaps a
> compressed representation of large chunks of allocated contiguous blocks.
One problem with the DOS/WIN95 FAT8/FAT12/FAT16/FAT32 file system is that
the table is actually a kind of linked list with each position containing
the location of the next block in the file (zero indicates the last block
in the file and -1 [FFF] an unused block). DOS1 & DOS2 used an 8bit value
for each location and a single cluster for the FAT table limiting the size
of a disk. Later versions increased both the cluster size, the FAT entry
size, and the size of the table itself allowing for larger drives.
However, since the FAT must live on the first few clusters of a disk and is
fixed size DOS file systems are not expandable. Also there is no
independent free space list so that potentially the entire FAT needs to be
searched to find a free cluster.
Another problem stemming from the location of the FAT is that any
modification of a file or directory requiring the allocation of a new
cluster to a file requires a write to the beginning of the drive as well as
any data writes otherwhere on the drive. DOS does not read the entire
block chain for a file when the file is opened and must walk the list of
blocks belonging to the file over and over as the file is read. Even if a
disk cache caches the FAT this can be slow.
Other schemes include the UNIX inode method which tracks space allocation
in a linked list of block ids attached to the file's inode. The file's
directory entry(s) contain the inode number and this separation of name
(directory entry) and file (inode) is what allows UNIX to have links and
aliases (symbolic links) (ie multiple directory entries) for the same file.
It also locates the "FAT" entries in the inodes closer to the file's data
and the directory files speeding updates. Free disk blocks are maintained
in a special inode like linked list known as the "freelist" so that new
blocks can be allocated quickly. When a file is opened the first inode
block is read into memory and it contains the pointers to the files first
256 disk blocks and a pointer to the next inode page containing more
pointers. A single extra operation is needed to read all of the blocks of
a file up to 128MB, only 2 more extra operations for the next 128MB etc.
The largest problem is the entire DOS I/O function structure. DOS is not
an optimized operating system and so Linux instances can read and write to
DOS file systems faster than native DOS on the same machine.
Art S. Kagel, kagel AT bloomberg DOT com
- Raw text -