Re: [nfsv4] Read delegations and LOCK operation

["Noveck, Dave" <Dave.Noveck at netapp.com>]

Agree with your statements.

I'm not working on the basis of any authoritative knowledge of mandatory
lock semantics.  I'm assuming that a READ lock prevents WRITEs and not
READs because nothing else seems to make sense.

That is, a WRITE lock prevents both READs and WRITEs, presumably because
you are changing the area and you don't want anyone to interfere with
your changes or see the that area of the file without the changes being
completed.  If that's the case, then if a READ lock prevents READs then
it would almost certainly have to prevent WRITEs as well and so it would
be exactly the same as a WRITE lock and so be pointless.  On the other
hand, a READ lock that prevented WRITE locks and WRITEs in that area
would make perfect sense.  You want to see a consistent state of that
area for your set of read and don't want anyone changing things while
your locks is held.  That would be consistent with N clients each hold
their own READ lock for the same or overlapping areas.

-----Original Message-----
From: Rick Macklem [mailto:rmacklem at uoguelph.ca] 
Sent: Friday, October 16, 2009 10:51 AM
To: Noveck, Dave
Cc: Sandeep Joshi; nfsv4 at ietf.org
Subject: Re: [nfsv4] Read delegations and LOCK operation




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.