On Wed, 2020-07-01 at 14:14 -0700, Frank Filz wrote:
> On Wed, 2020-07-01 at 11:39 -0700, Frank Filz wrote:
> > Yea, the notify lock callback is not supported, that would take some
> > effort to implement non-blocking locks for NFS v4.1 which is
> > complicated in that I'm not sure if the callback is a guaranteed deal
> > , that the client will send some kind of cancellation if it gives up
> > waiting for a blocked lock
>
> There's nothing guaranteed. The client can always just drop off the net.
> In knfsd, we just assume that the lock will be revisited at least once each lease
> period, and just drop the blocked request if they aren't. The Linux kernel
client
> will still re-poll for the lock every 30s if it doesn't get a notification.
>
> > , If not, then we need to time out 4.x blocked locks. We also have to make
> them provisional until the client actually comes back with a new lock request,
> which means they COULD be handed out to another client in the meantime.
>
> A v4.1 CB_NOTIFY_LOCK is _completely_ advisory. It just says "this is a good
> time to retry that lock you wanted". There's never a guarantee that
you'll get it
> and the server is under no obligation to hold it for the client being notified.
This
> is fundamentally different from (and simpler
> than) NLM.
Ok, so the 4.1 blocks would have to be maintained on a list in order of most recently
polled. Then the reaper thread would look at the LRU of the list and release any wait for
notification entries that have expired until it hits one that hasn't expired.
Yep -- that's more or less what we do in knfsd.
> > This provisional (or courtesy) behavior may be hard to
assure in a cluster or
> even a single node where there are other processes using locking on the same
> file system (since the courtesy lock would be a normal held lock on the backend -
> Ganesha can only give a conflicting lock out and cancel the courtesy lock for
> locks that come through that Ganesha instance).
>
> I think it's probably possible to do it with some FSALs. For example, it'd
probably
> be doable in libcephfs and then we could wire that into nfs-ganesha. FSAL_VFS
> (and similar) might actually be the toughest place to make it work, since the
> kernel would need new interfaces for it.
Yea, I assume it would be straightforward to implement in Ceph, tying somehow into the
caps logic. And yea, FSAL_VFS would either have to modify the kernel, or it could just
wait on a blocked lock, and then when the blocked lock is granted, immediately drop it and
send a notification.
Technically, file locking is handled outside the caps subsystem, but it
should be possible to do something that we could plug ganesha into. Not
saying it'll be _simple_ but that's a lot simpler to deal with that than
new kernel interfaces. :)
--
Jeff Layton <jlayton(a)poochiereds.net>