From owner-freebsd-hackers  Sun Feb  4 23:39:30 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id XAA09214
          for hackers-outgoing; Sun, 4 Feb 1996 23:39:30 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA09207
          for <hackers@freebsd.org>; Sun, 4 Feb 1996 23:39:14 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id SAA02716; Mon, 5 Feb 1996 18:34:42 +1100
Date: Mon, 5 Feb 1996 18:34:42 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199602050734.SAA02716@godzilla.zeta.org.au>
To: hackers@freebsd.org, rnordier@iafrica.com
Subject: Re: FAT filesystem performance
Sender: owner-hackers@freebsd.org
Precedence: bulk

>> > 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