On Tue, 10 Apr 2001, Matt Dillon wrote:
> :I'm curious about the other things though ... FreeBSD still seems
> :to have the early 90's abstraction layer from Mach and the vnode
> :cache doesn't seem to grow and shrink dynamically (which can be a
> :big win for systems with lots of metadata activity).
> Well, the approach we take is that of a two-layered cache.
> The vnode, dentry (namei for FreeBSD), and inode caches
> in FreeBSD are essentially throw-away caches of data
> represented in an internal form. The VM PAGE cache 'backs'
> these caches loosely by caching the physical on-disk representation
> of inodes, and directory entries (see note 1 at bottom).
>
> This means that even though we limit the number of the namei
> and inode structures we keep around in the kernel, the data
> required to reconstitute those structures is 'likely' to
> still be in the VM PAGE cache, allowing us to pretty much
> throw away those structures on a whim. The only cost is that
> we have to go through a filesystem op (possibly not requiring I/O)
> to reconstitute the internal structure.
Which is ok if there isn't too much activity with these data
structures, but I'm not sure if it works when you have a lot
of metadata activity (though I'm not sure in what kind of
workload you'd see this).
Also, if you have a lot of metadata activity, you'll essentially
double the memory requirements, since you'll have the stuff cached
in both the internal structures and in the VM PAGE cache. I'm not
sure how much of a hit this would be, though, if the internal
structures are limited to a small enough size...
regards,
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com.br/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message