Bill Studenmund <wrstuden@netbsd.org> writes:

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

Yes, we need either to make sure lower vnode aren't reclaimed during
reactivation or to know that they are reclaimed.  Similar race will
occur while upcalling since upper vnode may be on the free list (but
probably easier to solve since can be processed one by one).

Since we need to reactivate while searching cached node, we can just
return `not found' if failed to reactivation.  Am I missing something?

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

No, not yet.  Could you please give me a pointer?

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

Hmm.

enami.