Re: nfs locking for cluster filesystems

[Andrew Morton <akpm@linux-foundation.org>]

> On Tue, 17 Apr 2007 13:55:33 -0400 "J. Bruce Fields" <bfields@fieldses.org> wrote:
> On Thu, Apr 05, 2007 at 07:40:50PM -0400, J. Bruce Fields wrote:
> > If a filesystem defines a ->lock() method, that method is called when an
> > application uses fcntl(), but it isn't called from the code path used by
> > the lock managers (lockd (for nfsv2/v3) and nfsd itself (for v4)).  The
> > following patches remedy that.  (This hasn't been a problem until
> > recently because the filesystems that define ->lock (nfs, cifs, etc.)
> > aren't filesystems that nfsd exports.  The arrival of cluster
> > filesystems changes that.)
> > 
> > We'd like an ack from Trond and/or Christoph before this goes into
> > mainline, but it seems ready at least for testing in -mm.
> > 
> > The first four to six patches are actually just locks.c cleanup.
> 
> I've got an updated series addressing Christoph's comments (except that
> it's still using FL_CANCEL instead of a ->cancel() file method).  I was
> arguing with myself about what would be the least obnoxious way to send
> the update:
> 
> 	- resend all 17?  (Seems like mild overkill.)
> 	- resend just the last 10?  (The first 7 are identical to what's
> 	  in -mm.)
> 	- Send in an incremental patch?  (But I really wouldn't want
> 	  them submitted to the kernel that way.)

Yes, there's no perfect approach here, if the changes are too large to
permit the preferred approach of doing an incremental patch against each
main patch.

> 	- Ask you to fetch from the server-cluster-locking-api branch of
> 		git://linux-nfs.org/~bfields/linux.git

Well if we're all now happy with the level of review then a git tree is OK
by me.  I'll suck that tree down later in the week, will let you know if
anything goes wrong.