Re: Vnode API change: add global vnode cache

["J. Hannken-Illjes" <hannken%eis.cs.tu-bs.de@localhost>]

On 07 Apr 2014, at 18:02, Taylor R Campbell 
<campbell+netbsd-tech-kern%mumble.net@localhost> wrote:

>   Date: Mon, 7 Apr 2014 15:51:00 +0200
>   From: "J. Hannken-Illjes" <hannken%eis.cs.tu-bs.de@localhost>
> 
>   On 07 Apr 2014, at 03:22, Taylor R Campbell 
> <campbell+netbsd-tech-kern%mumble.net@localhost> wrote:
> 
>> Is the plan to nix getnewvnode and ungetnewvnode?  It would be good to
>> avoid long-term duplication of its body.  But I suspect we'll want to
>> keep those for, e.g., tmpfs, in which case this should use getnewvnode
>> and ungetnewvnode instead of vnalloc/setup/teardown/vnfree.
> 
>   Not sure if we have to keep getnewvnode() in the long term.
> 
>   It cannot be used here as we don't want the partially initialised
>   vnode (before VFS_LOAD_NODE) on the mnt_vnodelist.
> 
>   If we end up replacing getnewvnode() with a two-stage allocator that
>   initialises in the first stage and finalises in the second stage we
>   may use it here.
> 
> In that case, could you set the VI_CHANGING bit in vp, rather than
> node->vn_vnode = NULL in the vcache node, to indicate that the vnode
> is being initialized in vcache_intern?

This will not work for layered file systems.  They will share the
v_interlock from another vnode (in VFS_LOAD_NODE) so we better don't use
the interlock before loading the fs node.

>> Does anything use VFS_VGET in ufs now?  If so, why?  If not, this
>> should just fail.  (Eventually we ought to nix VFS_VGET, I think.)
> 
>   VFS_VGET() is used by NFS V3 readdirplus so we have to keep it.
> 
> Ugh bletch.  OK for now, but it would be nice if there were a better
> way to do this.
> 
> Perhaps we ought at least to change VFS_VGET so it returns the vnode
> unlocked, and once we do that, use it consistently to look up vnodes
> by inode number rather than calling vcache_intern in multiple
> different places.

Maybe in the far future.  Already looked at it and it is a very big job
if we want to do it in one step.

--
J. Hannken-Illjes - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig 
(Germany)