adding a lock flags argument to VFS_FHTOVP() for FreeBSD9

Zack Kirsch zack.kirsch at isilon.com
Thu May 19 01:09:53 UTC 2011


Btw, we've implemented exactly this at Isilon and do take SHARED locks instead of EXCLUSIVE for many operations. I'm definitely in support of the idea.
 
Zack

-----Original Message-----
From: owner-freebsd-fs at freebsd.org [mailto:owner-freebsd-fs at freebsd.org] On Behalf Of Rick Macklem
Sent: Monday, May 16, 2011 4:59 PM
To: FreeBSD FS
Subject: RFC: adding a lock flags argument to VFS_FHTOVP() for FreeBSD9

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.)

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?

rick
_______________________________________________
freebsd-fs at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"


More information about the freebsd-fs mailing list