Re: [NFS] [PATCH 10/10] gfs2: nfs lock support for gfs2

["J. Bruce Fields" <bfields@fieldses.org>]

On Thu, Dec 07, 2006 at 09:30:43AM -0600, David Teigland wrote:
> Some posix locks would be trivial to cancel and others would be hard.  If
> gfs_controld has not yet read the op from the kernel's send_list, then we
> just remove the op and it never "goes out".  After gfs_controld has taken
> it and sent it, then it's had its effect and, as you reminded me, is
> unreversible without introducing new complexity (like the provisional
> locks which sound unpleasant).

Something like that may be necessary in the end anyway.  The background:

NFSv4 doesn't have lock grant callbacks.  It only has a single lock
call.  You can set a "blocking" bit in that call, but all this does is
tell the server "I intend continue polling for this lock, so if it
becomes available, could you hold it a little while to give me a chance
at it before anyone else?"  That's just a hint, not a requirement.  But
if we don't take the hint, locking between clients with different
polling strategies, or between remote clients and local users, may be
dramatically unfair.

The client also isn't required to poll for the lock again--it may stop
without notice at any time.  So we'd like to have a way to hold a lock
on behalf of a client, without losing the ability to cancel the lock if
the client goes away.  Hence the provisional locks.

For now, maybe we could settle for a solution that at least handles
exclusive whole-file locking (for which an unlock is an adequate
cancel), and leaves open the possibility of a more complete solution
later.

--b.