Re: Vnode API change: add global vnode cache

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

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

>   Date: Wed, 9 Apr 2014 11:10:37 +0200
>   From: "J. Hannken-Illjes" <hannken%eis.cs.tu-bs.de@localhost>
> 
>   There is no need to do this VI_CHANGING etc. here.  Primary goal of
>   the vnode cache is to always initialise vnode / fs node pairs before
>   they become visible or appear on any lists.
> 
> But the vnode/fsnode pair effectively already does appear on a list,
> namely in the vcache -- it's just that you've added a new mechanism
> for waiting for the vnode's state to change so that *fs_vget now has
> to have two cv_wait loops, one in vcache and one in vget.
> 
> Either way, once someone has decided to create a vnode for an inode,
> and before the inode has been loaded from disk, everyone else wanting
> a vnode for that inode must wait for its state to change.  I don't see
> a compelling reason to have more than one mechanism to wait for vnode
> state transitions.

And I don't see a reason to use the same mechanism in vcache.  A newly
created vnode is invisible until it is fully loaded.

Changing vcache like you proposed would request file systems to set up
vnodes in two places, one the call to vcache_intern() where it has to
set type, ops and interlock and the second the load operation where it
has to set data, size etc.

To me it looks better if one file system operation has to set up the
full vnode state.

Do you object to the vcache API from the latest diff?

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