Slight change of vnode<-->vm object relationship.

[Stephan Uphoff]

On Tue, 2005-01-11 at 16:40, Poul-Henning Kamp wrote:
> Today a vnode gets its vm object through an explicit call to
> VOP_CREATEVOBJECT() and these calls are scattered all over the place
> in code which shouldn't really have to know about this detail.
> 
> It seems to me that it would make much more sense to make it became
> the responsibility of VOP_OPEN() and VOP_CLOSE() to manage the vnodes
> vm_object.
> 
> First of all, it gets put into the filesystem which implements the
> vnode, that's always cleaner, even if it just ends up calling a generic
> function to do all the work.
> 
> But second, and from a buffer cache perspective far more important
> reason: it makes the VOP_GETVOBJECT() call go away because the
> vp->v_object pointer will be stable as long as the vnode is open.
> 
> The vp->v_object pointer is likely to be valid also after the vnode
> has been closed, at least as long as there are cached pages in
> RAM for the vnode, but again the vp->v_object pointer will tell
> us that without a need to call down the stack of vnodes to find out.
> 
> For NULLFS/UNIONFS this works particular elegant:  on VOP_OPEN,
> the lower vnods v_object is copied to the upper vnode (I don't even
> think we need to grab a reference because we already have a reference
> on the lower vnode anyway).  On VOP_CLOSE we simply zero the v_object
> pointer on the upper vnode.  The lower vnode will still cache the
> object and pages, and if we open again, all we have to do is copy
> the pointer.
> 
> Anyone spot what I didn't ?

Do you mean VOP_INACTIVE instead of VOP_CLOSE ?
VOP_CLOSE is called for every close() call to the file - not just the
last close.

The NFS server also does not call VOP_OPEN - so this may be another
problem.

Stephan