Re: CVS commit: syssrc/sys/miscfs/nullfs

[enami tsugutomo <enami%sm.sony.co.jp@localhost>]

Bill Studenmund <wrstuden%wasabisystems.com@localhost> writes:

> On Sun, 17 Mar 2002, enami tsugutomo wrote:
> 
> > > But we can address this issue, if we want, by arranging for that vnode to
> > > go on the front of the free list rather than the end.
> >
> > No, it just makes the lower vnode reclaimed more earlier than it
> > should be.
> 
> I'm sorry, I misspoke. What I meant to suggest was that when we reclaim
> the layered node, we vrecycle() the lower one (if we were the last
> reference). That way both nodes die at about the same time.

No, no.  For example, if the lower vnode is once used directly in the
lower file system while it is cached in layer file system, the lower
vnode should be reclaimed much later than the layer file system node
(instead of same time).

> > > But why?  Why release and grab every time we go on or off the free list,
> > > when the times it matters (deletion below for instance) are rare, and
> > > well-defined?
> >
> > Since, IMHO, keeping reference when it isn't used actually is abuse.
> 
> Abuse of what? You feel strongly about this, but I'm still not clear on
> what excatly you feel strongly about and why.

As we (or only me?) saw, rest of kernel expects node is released when
it is no longer used.

> > Put vnode back to freelist when it isn't used anymore and reactivating
> > it when it becomes necessary later is what we do for other
> > filesystems.  Why we need to handle layerfs specially?
> 
> That is what we do for the layer vnode. But why should we do it for the
> lower vnode too? Releasing and reactivating the lower node each time we
> release and reactivate the upper one helps us catch a problem that happens
> infrequently, but involves adding extra steps to the common code path.

So, the lower filesystem or lookup code also implements own cache to
increase performance.

> Also, I can think of a number of other cool things to do with layered file
> systems which will need the exact same infrastructure as the one I'm
> describing for fixing removal, so let's just use it.

Ditto for purging cache entry.  If it can be done, it may possible to
put back vnode to the pool when memoy is really tight, (or more
dynamically resizing desiredvnodes).

enami.