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.

> > 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.

> > Think about a case where someone has a web server in a chroot environment,
> > and they have read-only null mounted the content into the chroot. Each web
> > page is going to result in a path lookup. All of the directories traversed
> > in finding a file will come into use (come off of free list), be used for
> > a lookup, and then go out of use (go back on the free list). If we don't
> > hang onto a ref on the lower vnode, each lookup now has to do a
> > reactivate. That seems wasteful to me.
>
> 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.

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.

Take care,

Bill