RFC: adding a lock flags argument to VFS_FHTOVP() for FreeBSD9

[Kostik Belousov]

On Mon, May 16, 2011 at 07:58:35PM -0400, Rick Macklem wrote:
> Hi,
> 
> Down the road, I would like the NFS server to be able to do a
>   VFS_FHTOVP(mp, &fhp->fh_fid, LK_SHARED, vpp);
> similar to what is already supported for VFS_VGET(). The reason
> is that, currently, when a client does read-aheads, these reads are
> basically serialized because the VFS_FHTOVP() gets an LK_EXCLUSIVE
> locked vnode for each RPC on the server.
> 
> Like VFS_VGET(), the underlying file system can still choose to
> return a LK_EXCLUSIVE locked vnode even when LK_SHARED is specified.
> (Some file systems, such as FFS, just call VFS_VGET() in VFS_FHTOVP(),
>  so all that happens is that the flag is passed through to VFS_VGET()
>  for those ones.)
Yes, the flag to specify the locking mode does only specify the minimal
locking requirements, and filesystem is allowed to upgrade it to the
more strict lock type. E.g. UFS would only return shared lock if the
vnode was found in hash, AFAIR. If not told otherwise, getnewvnode(9)
forces lockmgr to convert all lock requests into exclusive.

> 
> To minimize the risk of the patch breaking something, I have it setting
> LK_EXCLUSIVE for all VFS_FHTOVP() calls so that the semantics don't
> actually change. (Changing the NFS server to use LK_SHARED is a trivial
> patch, but will need extensive testing, so I'm not planning on that
> change for 9.0.)
> 
> If you are interested, my current patch is at:
>   http://people.freebsd.org/~rmacklem/fhtovp.patch
> 
> So, does this sound like a reasonable thing to commit, once the patch
> is reviewed?
Sure, please do it before the code slush.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20110517/e1783216/attachment.pgp