From owner-freebsd-hackers Mon Feb 5 12:35:36 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA21463 for hackers-outgoing; Mon, 5 Feb 1996 12:35:36 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA21453 for ; Mon, 5 Feb 1996 12:35:31 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA15459; Mon, 5 Feb 1996 13:31:54 -0700 From: Terry Lambert Message-Id: <199602052031.NAA15459@phaeton.artisoft.com> Subject: Re: FAT filesystem performance To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Mon, 5 Feb 1996 13:31:54 -0700 (MST) Cc: bde@zeta.org.au, hackers@FreeBSD.org, rnordier@iafrica.com In-Reply-To: <199602050837.JAA20312@labinfo.iet.unipi.it> from "Luigi Rizzo" at Feb 5, 96 09:37:21 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org Precedence: bulk > > 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. > > agreed. That's why I thought not to develop a special purpose caching > policy and try to rely on what is already available. Especally in > FreeBSD, where the FS & VM caches are merged, and the system should be > quite flexible. The problem with doing this is the mmap problem. That is, buffers are cached on the basis of vnode + offset instead of device + offset. Basically, this means that when you recycle vnodes, you must invalidate perfectly good data in the cache because there is no longer a vnode to point to it. This is critically bogus, IMO (do a find from / and listen to the "tick tick tick..." of the disk on a 16M machine, knowing less than 8M of blocks are being accessed, and the noise is unnecessary disk access from vnode recycling -- now you know why I wanted to move the VOP_LOCK code out of the per-FS and why I think dissociating a vnode with a seperate ihashget in ufs is >*BOGUS*<). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.