Subject: Re: Simple thought...
To: Greywolf <email@example.com>
From: Frank Kardel <Frank.Kardel@Acrys.COM>
Date: 06/11/2002 07:19:48
Greywolf <firstname.lastname@example.org> said:
> On Mon, 10 Jun 2002, Frank Kardel wrote:
> # With UBC ...
> I thought vnodes WERE metadata. Or is it that the _i_node data is the
> stuff (under the vnode) that gets cached and the vnode is just a pointer,
> and there's no cache for that?
vnodes are meta-data an a bit more basically the file abstraction.
There are inodes (and a few type more) associated with the vnodes.
If i remember right (no src access right now) the UBC data pages are
also hooked up at the vnode thus a vnode actually becomes an anchor for the
fs data cache.
So if you have few vnodes you got only few anchor points and thus poor
I hope i got it right from the reasoning - experimental results seem
to suppor my theory and if i could look at the source right now (time wise)
i could verify that.
> [I seem to recall that vnodes did get cached; they were the one parameter
> that if they maxed out (according to pstat) you didn't have to really
> worry about it (unlike files or swap space)...]
Thats right as old (inactive) vnodes would get re-claimed. But you would
constantly lose you cache anchor points when your file working set
exceeds the vnode count.
> Is there a tool that displays buffer cache statistics in some form?
> I don't think pstat is what I want for that (although it does show the
> open file table...), and I don't think vmstat is what I want, either...
> [It would be interesting to see the buffer cache's references. Useful?
> Probably not on a large scale. But as I'm not well-versed in kernel
> hacking, I'm curious to see what's there...]
see systat buf (sort of real time display - even gives you the bufcache
Acrys Consult GmbH