Re: [nfsv4] Read delegations and LOCK operation

[Rick Macklem <rmacklem at uoguelph.ca>]

On Thu, 15 Oct 2009, Noveck, Dave wrote:

> I think the argument to be made is that when you have read delegations,
> you have already prevented writes and in that case a mandatory READ lock
> is a no-op in that it doesn't prevent any IO's that would not be
> prevented otherwise.  That is, it only would prevent writes and writes
> are already prevented by the fact that you have a read delegation.  Any
> writes or opens for write would already recall the delegations.  So I
> think you could argue that in that case, for such locks, the server is
> not implementing "mandatory lock semantics" because in the case of such
> locks you can't get to any situation in which the mandatory lock
> semantics' behavior is different from that of the non-mandatory
> semantics.  In that somewhat strange context, a change in the text would
> only have to make explicit what is already implicit, but might well
> confuse people into recalling delegations when they don't need to be
> recalled.
I'm not particularily familiar with mandatory lock semantics.
- If client X wants to read a byte range of a file, when it doesn't
  hold a read lock on that range, but client Y does hold a read lock
  on that byte range, is the Read allowed?
  (Yes, I realize that client X could acquire a read lock on the byte
   range, but if it hasn't bothered to do so...)

If the answer to this "Yes, the read is allowed", then I'd agree
in that I can't think of why the Read delegations would need to be 
recalled. If the answer is "No, the read is not allowed", then I'd say 
that the current text is correct, since the server can only know what byte 
range(s) are locked by which clients by recalling the delegations.

rick, who doesn't believe read delegations are much use anyhow.