Subject: Client <-> Server Lock Synchronization

From: "Stevan Steve Allen" <[email-masked]>
Date: Mon, 12 Aug 2002 11:24:17 -0700

We're concerned with the ability to keep the Client & Server locking
records in sync while supporting delegation.  If the client needs to
transfer locks to the server (reclaim, recall), and if the server does not
support the lock request already granted by the client, the associated data
buffers will be lost.

Our concerns are in two areas.

----------------
o NFS4ERR_Lock_Range may not be detected prior to delegation
----------------

If an Open delegation is granted prior to any locking requests, the server
state described by NFS4ERR_Lock_Range may not be detected by the client.
If the client "locally" implements subrange locking, delegation recall may
fail lock requests already granted by the client.

I have not found a value either prior to or during an OPEN delegation
response to indicate the NFS4ERR_Lock_Range server state... If none exists,
the following looks appropriate for additional server locking support
indicators, 14.2.16 "The rflags returned by a successful OPEN allow the
server to return information governing how the open file is to be handled."

----------------
o Unknown locking techniques implemented by various servers
----------------

Seems proper to prevent failures during lock reclaim or recall.  The client
should detect server locking capability and may locally reject any request
not supported by the server.  We are not sure the client can detect "all"
implemented locking abilities.

  NFS4ERR_ROFS        Read Only file system returned on
  NFS4ERR_Lock_Range  Server does not support subrange unlock or promotions
  NFS4ERR_NotSupp     A unique lite locking implementation <?>
  NFS4ERR_Inval       For blocking, hanging blocking requests on the client
lock queue seems fine
                      as there is no associated modified data buffer for
the request

I suspect our client should perform _ROFS and _LOCK_RANGE restrictions
locally if indicated by the server to properly support functions such as
delegation, test lock, and reclaim.  Any NFS4ERR_INVAL and NFSVERR_NOTSUPP
conditions should be returned to the application when detected (recall).

----------------
o Summary
----------------

I would like to see similar verbiage in the protocol.. the server may
decline delegation if it can not implement full subrange locking or emulate
a locking technique returned in rflags.  During delegation if the client
implements locking not supported by the server, lock requests may fail
during recall or reclaim.  In this event, the client may invalidate
modified buffers protected by the failed lock if the client can not protect
the data with a server lock.  To prevent failures during recall, the client
may detect server locking capability and locally reject any request not
supported by the server.

We discussed the life of the NFS4ERR_Lock_Range state being recorded by the
client and the state looks best handled at the file level when considering
cross mount points.  comments?

Did we miss any NFSV4ERR server capability indicators (not listed above)
which pertain to known server locking capabilities (or lack thereof)?

Thanks,
Stevan C. Allen
NFS Development

[ Perfection is when nothing else can be removed ]
[ Simplicity provides the best returns on investment ]

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 19 Aug 2002 23:22:46 -0500

> support the lock request already granted by the client, the associated data

In general, if the application has not closed the file yet, there is
still an appropriate opportunity to notify the application of the
failure at the server and is not much different than the server
returning an error on writing of file data because of other errors.
The only application affected will be the one at the client holding
the delegation and no others.

> Our concerns are in two areas.

NFS4ERR_LOCK_RANGE is meant to signify a server that does not support
a sub-range lock of an existing lock.  It is not meant to signify a
server that does not support any type of sub-file locking.

Therefore, if the client, upon recall, finds its locking requests are
not supported directly by receiving the NFS4ERR_LOCK_RANGE error, the
client can combine the existing locking state such that the requests
are not subrange requests and send those locking requests to the
server (which will be serviced) and proceed to write any modified
data.  At this point, the client can then reject any further file
locking requests since it now knows the server does not support
sub-range locking requests.

First the server should not allow an OPEN for write on a filesystem
that is read-only.  Furthermore, it shouldn't be providing a write
delegation for a read-only filesystem.

>   NFS4ERR_Lock_Range  Server does not support subrange unlock or promotions

As per above, the client shouldn't require this knowledge prior to
delegation.

>   NFS4ERR_NotSupp     A unique lite locking implementation <?>

NFS4ERR_NOTSUPP is NOT listed for the LOCK, LOCKU operations.  They
MUST be implemented per the specification.

>                       as there is no associated modified data buffer for

? This doesn't make sense since the protocol does not provide for
blocking locks (we only have a hint that this is what the client is
trying to do) and the client is required to resubmit the lock request
if it is trying to provide blocking semantics.

> conditions should be returned to the application when detected (recall).

For a read-only filesystem, the client has no choice but to pass the
failure back to the application.  For LOCK_RANGE, the client has the
choice of implementation to pass this failure to the application or
attempt to simulate the sub-range behavior (even though it will not be
atomic).

I am not sure I see any need for modifications to the spec based on
the above.  The server decides whether it will provide a delegation to
the client purely on it own.  If the server does not support subrange
locking, that must not restrict its ability to provide a delegation.
I think it is clear that if locking requests are attempted as part of
a delegation recall that they may fail with LOCK_RANGE.  That is the
standard behavior for file locking.

> cross mount points.  comments?

I would consider the LOCK_RANGE error to be per filesystem.

> which pertain to known server locking capabilities (or lack thereof)?

NFS4ERR_BAD_RANGE

-- 
Spencer