Bill Studenmund <wrstuden@netbsd.org> writes:

> > One of such action is to reclaim on disk storage.
> 
> That's the whole point of what we were talking about for VOP_UPCALL().
> When the lower layer notices the file is fully unlinked, it calls a
> routine (v_upcall for now) and passes a command (like an ioctl). v_upcall
> vgets() each upper node, calls the node's VOP_UPCALL() routine, and steps.
> When each layer gets a VOP_UPCALL() that says the lower vnode has been
> released, it takes steps so that when the layer (upper) vnode is
> inactivated, it instead gets vrecycle()d.
> 
> There are some issues I'm not sure of about exact details, but this very
> issue is why I/we came up with the idea. :-)

For example, ufs_inactive does VOP_UPDATE().  This means the time
recorded on disk becomes the time when upper vnode is reclaimed.  How
do you fix this?

> > > Hmm.. I just thought of a strong reason why we NEED the upper vnode to
> > > reference the lower one. The lock for the upper one is the same as the
> > > lower one - they use the same struct lock, which is located in the lower
> > > vnode. As long as that is the case, the upper really needs to hang onto
> > > the lower one.
> >
> > Even when the upper vnode isn't used?
> 
> Depends on how we do inactivation and reactivation. It either uses the
> lower vnode's lock, or we have to swap locks around. And we will likely
> get in a case where we have two locked locks and we have to merge them.
> That sounds like a real mess to me.

Keeping reference while it is really not used is also sounds mess.
So, which one is bigger?

> > Of course, in upper vnode's vget(), it should vget() the cached lower
> > vnode.
> 
> vget() doesn't call the vnode's file system.

Please rephrase me that when upper vnode is vget()'ed.

enami.