Re: rototilling the vnode life cycle

[David Holland <dholland-tech%netbsd.org@localhost>]

On Fri, Feb 28, 2014 at 03:41:33PM +0000, Taylor R Campbell wrote:
 > Also, I propose we nix the terms `recycle' and `reclaim' (except for
 > VOP_RECLAIM, until we rename it to VOP_DESTROY).  When we're done with
 > a vnode, we destroy it and free its memory.  When we want to grab it
 > from the inode cache, we get it, or perhaps grab it.

Yes please.

Although remember that if you unlink an object and drop it, then
create a different object with the same inode number, you (may) still
get the same vnode back. This is still a recycle of sorts from the
FS's point of view, although it shouldn't matter much.

 > (s/vget/vgrab/1,
 > so we are not linguistically motivated to parallel vput?)

As long as we have something with more or less the same weird
semantics (that is, get the first reference to an "unreferenced" vnode
in the/a vnode table) let's keep the name vget.

When we get rid of that in favor of a centralized vnode cache, it
should be something different entirely like vn_fetch or vn_lookup or
even vn_find.

vput should just go away, and I'd like to rename many of the other
functions to be more systematic, e.g. vref -> vn_incref, vrele ->
vn_decref, vhold -> vn_inchold, and so on.

 >    Hold counts are still broken.  They were introduced to prevent the
 >    the vnode from recycling.  I suspect most users of vhold are more
 >    or less wrong.
 > 
 > If so, I totally misunderstood them -- but I believe that is how the
 > current vfs_vnode.c interprets the hold count.  How would it be
 > different from the usecount as you describe?

My understanding is that holds are weak references used for
backpointers to the vnode from things that hang off the vnode, like
buffers. But this may not be accurate.

 > I think you're right that most of the three users are wrong: udf and
 > lfs probably meant to use vref.  But it's not clear to me that the one
 > call in uvm_page.c is wrong -- if vfs decides to destroy that vnode,
 > it will call VOP_PUTPAGES to force those pages to their backing store.

I think the reason lfs uses vhold is that the reference count might be
(or, might always be) zero, in which case vref would panic. eeh
changed it to vhold from lfs_vref in 2009. (Using vhold seems ok to
me; lfs_vref itself looks highly bogus and it probably needs to go
away...)

A casual look at udf suggests that it's using vhold for the same
reason.

I guess the issue, or one of the issues, is that things that traverse
the vnode table may want to take out their own references; but because
the "reference count" of a vnode is 0 when it's in the vnode table but
not otherwise in use, this collides with the recycle logic that needs
the "first" reference to be taken out with vget and not vref.

The buffer cache seems to be the only other user of vhold. The uvm
usage and the buffer cache usage appear to be doing more or less the
same thing. This is for a different reason, namely what I said above:
weak references that are backpointers and would otherwise be cyclic.

(There's a vholdl call in the new freebsd NFS code but it looks like
logic we'll have to replace anyway so let's not worry about it.)

I have never liked setups where you keep objects around when they have
zero refcount. Maybe after we get rid of vget we can find a way to
rearrange this.

-- 
David A. Holland
dholland%netbsd.org@localhost