Date: Mon, 5 Feb 1996 13:31:54 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Cc: bde@zeta.org.au, hackers@FreeBSD.org, rnordier@iafrica.com Subject: Re: FAT filesystem performance Message-ID: <199602052031.NAA15459@phaeton.artisoft.com> In-Reply-To: <199602050837.JAA20312@labinfo.iet.unipi.it> from "Luigi Rizzo" at Feb 5, 96 09:37:21 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602052031.NAA15459>