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 dholl...@netbsd.org