Date: Sun, 23 Sep 2001 00:50:21 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: David Greenman <dg@root.com> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>, bright@wintelcom.net, hackers@FreeBSD.ORG Subject: Re: Conclusions on... was Re: More on the cache_purgeleafdirs() routine Message-ID: <200109230750.f8N7oLI85253@earth.backplane.com> References: <88901.1001191415@critter> <200109222121.f8MLLHe82202@earth.backplane.com> <20010922141934.C28469@nexus.root.com> <200109230642.f8N6gPj84955@earth.backplane.com> <20010922235704.D28469@nexus.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
: Hmmm. This would seem to be a step back to the days when caching was done
:relative to the device as opposed to the file-relative scheme we have now.
:One of the problems with the old scheme as I recall is that some filesystems
:like NFS don't have a 'device' and thus no physical block numbers to
:associate the cached pages with. There is also some cost in moving the pages
:between the file object and the device object. For these reasons, I would
:prefer that we keep the existing model, but just make sure that we can
:handle the degenerate case of one page per file object.
:
:-DG
:
:David Greenman
Yah. For NFS we'd have to just throw the pages away. I'm not changing
anything any time soon, I've got lots of other interesting stuff on my
plate. It's just an idea. The filesystem already has a VM Object
that it uses for inodes and bitmap blocks and such, this would simply
be a way to leverage it. Ultimately it may not matter... perhaps we
can devise a way of hanging onto the inode/vnode reference without
eating up so much KVM. For example, the VM Object could be associated
with the filesystem inode cache at the filesystem level. Or something
like that.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200109230750.f8N7oLI85253>