Re: Vnode API change: add global vnode cache

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

On Sat, Apr 26, 2014 at 07:22:50PM +0000, David Holland wrote:
 >  - It seems to me that in the long run, all of this baloney should be
 > hidden away inside the vfs layer; filesystems that use the vnode cache
 > should only need to call vcache_get, and the only thing that should
 > ever see a partially initialized vnode is VOP_LOAD and nothing outside
 > the vnode cache should ever see a vnode with refcount zero. This in
 > particular means that all the various forms of vget() should be hidden
 > away, as should getnewvnode.

As I discovered while prodding lfs last weekend, this is too
optimistic, as there's another family of cases: allocating a new inode
and constructing a vnode for it.

It is *possible* to do this by allocating an inode number and then
using vcache_get to procure the vnode, such that when the vnode cache
calls VFS_LOADVNODE it will load a blank inode. This is what ffs does,
and it works fine there since unallocated inodes have fixed known
locations that are in a known on-disk state.

It doesn't work for lfs, and it won't work for any other filesystem
where inode locations aren't fixed, at least not without some ugly
hackery: you can update the fs state with a location for the new
inode, and write a buffer with the intended inode contents, and then
have VFS_LOADVNODE find and use this buffer, but this is inefficient
and gross. (This isn't itself adequate for lfs because lfs has some
additional self-inflicted issues.)

After sleeping on this a few times, ISTM that the best way to handle
this is as follows:

   - add an additional call vcache_new to the API;
   - have vcache_new take a type argument;
   - have vcache_new assert that no vnode with the same key already
     exists (FS-level locking should guarantee this);
   - have vcache_new call a new op VFS_NEWVNODE instead of
     VFS_LOADVNODE and pass the type in.

(Other things I don't like so much including passing flags or other
information through vcache_get to VFS_LOADVNODE, or giving vcache_new
a preconstructed new vnode.)

Thoughts? I'll try to make time to prepare a patch this weekend.


...note that LFS would still like to be able to pass info through to
VFS_LOADVNODE, because sometimes it already knows the physical disk
location of an inode when it's calling vcache_get and sometimes it
doesn't. But I think this is a different issue and should be addressed
separately.

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