Date: Mon, 5 Feb 1996 18:34:42 +1100 From: Bruce Evans <bde@zeta.org.au> To: hackers@freebsd.org, rnordier@iafrica.com Subject: Re: FAT filesystem performance Message-ID: <199602050734.SAA02716@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> > The FAT-caching in the MACH implementation (you *could* just port the >> > MACH code...) takes a significant amount of memory, IMO. >> >> Hmm... FAT can contain at most 64K of entries, each 2 bytes long, so >> the needed amount of memory (if you cache raw FAT and don't try to make >> any ``cooked'' version) must be at most 128Kbytes long. IMHO the raw FAT >> is enough convenient ant takes not very much of memory. >Agreed. >This is what the original author of the MS-DOS filesystem had to say on >the subject of caching: > The new MS-DOS [ie. DOS 2.0] does not keep the file > allocation tables in memory at all times. Instead the > tables share the use of sector buffers.... This change > in the DOS goes completely against my original design > principles.... Now we're back to doing disk reads just > to find out where the data is. > -- Tim Paterson, Byte, June 1983. I wonder if he thought about maximal FATs with 64K * 1.5 byte entries. They would barely fit on a 160K floppy :-). 128K is quite small now, but it still isn't necessary to lock it into memory. Caching it in a normal LRU way should work reasonably well. Perhaps FAT buffers should have a higher priority than other buffers for msdosfs, but they probably shouldn't have higher priority than buffers for other file systems. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602050734.SAA02716>