On 26 Mar 2002, enami tsugutomo wrote:

> Bill Studenmund <wrstuden@netbsd.org> writes:
>
> > I'm not sure if I understand your question.
>
> I'm also not sure if I understand all your explanation :-).

Fair enough. :-)

> > My thought is that when the only references on the collections of vnodes
> > (because we could have a layer or two on a layer) are other layer vnodes,
> > we call a routine which uses the VOP_UPCALL() (or whatever it becomes) to
> > tell all the vnodes that the whole collection is now only on the free
> > list, and that the nodes with references should preform special
> > on-freelist processing. i.e. for ufs, VOP_UPDATE(). Not all of the nodes
> > will be in the free list, so they shouldn't do all the inactivate
> > processing.
>
> When do you check it?  Whenever a vnode is released?

Yes.

There's going to need to be a tree-walking routine. You'd call it and give
it a vnode and an operation to perform on that vnode tree. One operation
would be to count the number of non-layer references. Another one would be
to tell the upper vnodes to recycle themselves rather than inactivate (for
the deletion case). And from this discussion, there would be a third that
counted the number of non-layer references, and if there were zero, it
would tell the nodes in the middle that they are part of an aggregate
vnode that is on the free list.

> > We could, but how do we re-establish that reference? The problem is
> > that it is perfectly valid to take the inactivated vnode off of the
> > free list and start using it. Without a call to the file system's
> > code (there is no VOP_REACTIVATE()). So how do we do that
> > establishment?
>
> Yes, we don't have necessary machinary.  Probably we need to hook two
> case, one is when vnode is get off from free list to reuse for the
> same purpose (reactivated) and other is to reuse for different purpose
> (recycled).

The problem though is that we have a race condition. Until the layer node
vget()'s the lower node, something else could ask for a new vnode, and it
will get reclaimed. So then we'll have the upper vnode with nothing under
it. _And_ no way of getting it back.

Because the only way we can build layer vnodes up is over lower ones which
certain VOPs return, I think the upper node needs to hang onto a reference
on the lower node. If we loose it, too many bad things happen.

Have you read John Heidemann's dissertation? That's where a lot of the
ideas behind our layered file system come from (though with adaptations).

One of the ideas he talks about is caching data at the top of a stack. It
doesn't make much difference with only one layer, but with more than one,
it can really help. I'd like us to be able to do that. Also, it makes
sense to not destroy those cachings when the upper node goes on the free
list since it might get re-used. But if we have upper nodes caching
things, I'd really like there to be a clear path to the node with the
caching. The idea I came up with of having a list of nodes layered over
one was one way of doing it.

Take care,

Bill