From owner-freebsd-hackers  Mon Feb  5 08:09:18 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id IAA05541
          for hackers-outgoing; Mon, 5 Feb 1996 08:09:18 -0800 (PST)
Received: from eac.iafrica.com (slipper119221.iafrica.com [196.7.119.221])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA05525
          for <hackers@freebsd.org>; Mon, 5 Feb 1996 08:08:58 -0800 (PST)
Received: (from rnordier@localhost) by eac.iafrica.com (8.6.12/8.6.12) id RAA00183; Mon, 5 Feb 1996 17:53:49 +0200
From: Robert Nordier <rnordier@iafrica.com>
Message-Id: <199602051553.RAA00183@eac.iafrica.com>
Subject: Re: FAT filesystem performance
To: luigi@labinfo.iet.unipi.it (Luigi Rizzo)
Date: Mon, 5 Feb 1996 17:53:48 +0200 (SAT)
Cc: bde@zeta.org.au, hackers@freebsd.org
In-Reply-To: <199602051231.NAA20897@labinfo.iet.unipi.it> from "Luigi Rizzo" at Feb 5, 96 01:31:51 pm
X-Mailer: ELM [version 2.4 PL24 ME8a]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
Precedence: bulk

On Mon, 5 Feb 1996, Luigi Rizzo wrote:

> > > I wonder if he thought about maximal FATs with 64K * 1.5 byte entries.
> > > They would barely fit on a 160K floppy :-).
> 
> Pardon me, 1.5 byte entries mean by defiitiion at most 4K entries,
> i.e. 12K total per two FATs. Fits nicely on a disk!

Well, to get _really_ technical a 160K floppy only requires 1K of FAT
space (313 clusters).  And the 12-bit maximum is less than 4K due to
reserved values, but I think this all misses the point of the remark.  

> > I'd go along with that: and certainly not the msdosfs at the expense of
> > other fs-es.  One thing they did find with the MS-DOS LRU scheme was that
> > FAT sectors tended to "un-cache" too readily.  Different prioritization
> > could resolve that.

> All the above is correct, but keep in mind that it depends a lot
> on how many BUFFERS=xxx you declare in your config files.

Changing your 'buffers' setting isn't going to specifically affect the
problem of dropping FAT sectors from the cache.  You need weighted LRU
for that.

>                                                             And this is
> often a small number, which explains the poor performance of the cache.

Sometimes small numbers are bad; sometimes small numbers are good -- when
running smartdrive, for instance. :-)

-- 
Robert Nordier