Date: Thu, 11 Sep 1997 16:39:59 -0400 (EDT) From: "Art S. Kagel" To: Paul Derbyshire Cc: djgpp AT delorie DOT com Subject: Re: The is world dropping MS-DOS. What about DJGPP? (Was Re: Quake In-Reply-To: <5ute02$9ah@freenet-news.carleton.ca> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk 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