[nfsv4] Re: RFC: new MUTEX_BEGIN/MUTEX_END operations

[Chuck Lever III <[e-mail]>]

> On Aug 8, 2024, at 4:36 PM, Rick Macklem <[e-mail]> wrote:
> 
> Hi,
> 
> Over the years, I've run into cases where it would be really
> nice to be able to perform multiple NFSv4 operations on a
> file without other operations done by other clients
> "gumming up the works" by changing the file's data/metadata
> between the operations in the compound.
> 
> So, what do others think about an extension to NFSv4.2 that
> adds 2 new operations:
>   MUTEX_BEGIN(CFH)
>   MUTEX_END(CFH)
> Both would use the CFH as argument, and no other client would
> be allowed to perform operations on the CFH between the MUTEX_BEGIN
> and MUTEX_END.
> 
> I think there would need to be a couple of properties for these:
> - There would need to be an "implicit" MUTEX_END when any operation
>   between MUTEX_BEGIN and MUTEX_END returns a status other than NFS_OK.
> - I think you would want a restriction of only one mutex for one CFH
>   at a time in a compound. Without that, there could easily be deadlocks
>   caused by other compounds acquiring mutexes on the same CFHs in a
>   different order.
> - Only one compound can hold a mutex on a given CFH at any time.
> - MUTEX_BEGIN/MUTEX_END can only be used in compounds where SEQUENCE
>   is the first operation.
> - All mutexes are discarded by a server when it crashes/recovers.
>   (Any time a client receives a NFS4ERR_STALE_CLIENTID.)
>   That way RPC retries after a server reboot should work ok, I think?

I favor a narrow reservation, as described here, rather than
blocking all server operations. The usage for multiple files
would be more complicated, as Tom says, but my intuition is
that the server's implementation of a mutex might be more
efficient for the single file, which might be the common case.

Also, I think this needs to be explicitly tied to the client's
lease so that a mutex reservation evaporates automatically if
the client goes away.

This could be used as a DoS vector; care should be taken to
describe how a server mitigates or prevents clients from
accidentally or maliciously blocking operations on a FH
permanently.


> I am not sure what the semantics for reading data/metadata should be,
> but I was thinking that would be allowed to be done by compounds for
> other clients for the CFH. If a client wanted to serialize against
> other compounds for the CFH, it could do a MUTEX_BEGIN/MUTEX_END.
> 
> I see this as useful in a variety of ways:
> - The example in the previous email of:
>   MUTEX_BEGIN
>   NVERIFY acl_truform ACL_MODEL_NFS4
>   SETATTR posix_access_acl
>   MUTEX_END
> - Append writing:
>   MUTEX_BEGIN
>   VERIFY size "offset in WRITE that follows"
>   WRITE "offset" etc
>   MUTEX_END
> - A bunch of cases where NFSv4 lacks the postop_attributes
>   that were in NFSv3.
>   MUTEX_BEGIN
>   WRITE
>   GETATTR size, change,..
>   MUTEX_END
> 
> So, what do others think?
> (This was obviously not possible without sessions.)
> 
> rick
> 
> 
> _______________________________________________
> nfsv4 mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

--
Chuck Lever