Re: [nfsv4] Read delegations and LOCK operation

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

> ... possibly Sandeep and you are missing something.

I find that hard to believe :-).

> Mandatory byte range locking requests that there 
> always be a byte range lock that encompasses the 
> byte range a process or client reads or writes.

Can you point me to something that says that?  I've been googling
looking for some clear specification of what mandatory byte range locks
actually do, but this seems hard to believe.  It means that if you set
the mode bits indicating mandatory locking, you can't do an ordinary
read of the file; you would need a special program that did locks around
the reads.

It seems to make more sense for it to allow IO unless mandatory locks
held to prevent it.  I thought the mandatoriness of mandatory locks were
that they had to be to be obeyed when they were used, not that it was
mandatory to use them.

But I have no direct experience here and I wasn't able to find any clear
documentation.  I'm just going by what makes sense, which is not always
a perfect guide.
 
> OTOH, it might be case that the server is required 
> to account for mandatory byte range locks. E.g. if 
> client B tries to atomically upgrade its lock from 
> shared to exclusive, that attempt would require A's 
> delegation to be recalled. Perhaps the thinking was 
> (and this dates to RFC3530 and perhaps RFC3010) that 
> an "attempt" to atomically upgrade should not wait 
> for a recall.

Perhaps but what B is doing is getting a write lock and to me it makes
most sense to require that (i.e. getting a write lock) to cause a
recall, which it does.

> So perhaps when we wrote that text, we were invoking 
> the KISS principle.

Perhaps, or this could have been an oversight.  We don't know.

> It is also the case that in some operating systems mmap() 
> and exclusive byte range locking are mutually exclusive. 
> Read delegations are the moral equivalent of mmap().

Right but exclusive byte range locks are not the equivalent of mandatory
byte-range read locks.  They are non-exclusive.

> Regardless, I am not inclined to make any changes in NFSv4.1; 
> too late. 

Agreed.

> If mandatory byte range locking is becoming popular, then 
> I suggest addressing the issue in v4.2.

OK.

-----Original Message-----
From: Mike Eisler [mailto:mre-ietf at eisler.com] 
Sent: Wednesday, October 28, 2009 5:11 PM
To: nfsv4 at ietf.org
Subject: Re: [nfsv4] Read delegations and LOCK operation

I can't remember why the spec is the way it is, but ...

> It sounds to me like that is an oversight in the spec.  Am I (and
> Sandeep) missing anything here?

... possibly Sandeep and you are missing something.

Earlier in that section, the spec says:

"For example, Windows 2000 allows a write
   lock of a file open for READ, while a POSIX-compliant system does
   not.
"

Elsewhere the spec also says that:

"When a client holds a read open delegation, lock operations are not
   performed locally.  All lock operations, including those requesting
   non-exclusive locks, are sent to the server for resolution.
"

So I am wondering if these two statements provide the motivation for the
spec requiring a recall of delegations, even if a shared byte range
mandatory lock is sent.

Mandatory byte range locking requests that there always be a byte range
lock that encompasses the byte range a process or client reads or
writes.

Client A has a read delegation.

Client B has gets a mandatory byte range read lock.

If we don't recall the delegation, A does not know it mandatory byte
range locking is on. So its reads out of cache will not be protected
with byte range locks. This seems like a minor problem because the lack
of a byte range lock does not result in file corruption. OTOH, it might
be case that the server is required to account for mandatory byte range
locks. E.g. if client B tries to atomically upgrade its lock from shared
to exclusive, that attempt would require A's delegation to be recalled.
Perhaps the thinking was (and this dates to RFC3530 and perhaps RFC3010)
that an "attempt"
to atomically upgrade should not wait for a recall.

In thinking about this, rather than recalling a delegation because of
shared or exclusive byte range mandatory lock on the file, it would be
better to have a callback that informs the client that byte range
mandatory locking is in effect, and so all its reads from cache MUST
have explicit byte range locks sent to the server. Then, if a client
ever obtains a conflicting exclusive byte mandatory lock, the client's
read from cache will be properly denied. The read delegation would
continue to be in force. Of course, the value of a read delegation when
every read from cache has to be bracketed with a byte range LOCK/LOCKU
to the server is questionable.

So perhaps when we wrote that text, we were invoking the KISS principle.
It is also the case that in some operating systems mmap() and exclusive
byte range locking are mutually exclusive. Read delegations are the
moral equivalent of mmap().

Regardless, I am not inclined to make any changes in NFSv4.1; too late.
If mandatory byte range locking is becoming popular, then I suggest
addressing the issue in v4.2.

On Thu, October 15, 2009 2:58 pm, Noveck, Dave wrote:
> It sounds to me like that is an oversight in the spec.  Am I (and
> Sandeep) missing anything here?
>
> I'm not sure exactly what can be fixed at this stage without 
> triggering a re-entry into review, to be avoided.  I would expect that

> changing that paragraph to make it explicit that mandatory read locks 
> are OK, would be allowed.  I'd like Mike's and Spencer's opinion.
>
> 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.
>
> So my proposed text is:
>
>    When one or more clients hold read delegations, any LOCK request
>    where the server is implementing mandatory locking semantics, MUST
>    result in the recall of all such delegations.  In this context, a
>    read lock is not considered to be implementing mandatory lock 
> semantics
>    since the only operations that such locks prevents are WRITE's and
>    no such WRITE's can be done so long as the read delegations are
>    held.  Where mandatory lock semantics are being implemented for a
>    WRITE lock, the lock must
>    not be granted until all such delegations are return or revoked.
>    Except where this happens very quickly, one or more NFS4ERR_DELAY
>    errors will be returned to requests made while the delegation
remains
>    outstanding.
>
> Opinions?
>
> 	-----Original Message-----
> 	From: Sandeep Joshi [mailto:sjoshi at bluearc.com]
> 	Sent: Thursday, October 15, 2009 1:38 PM
> 	To: nfsv4 at ietf.org
> 	Subject: [nfsv4] Read delegations and LOCK operation
>
>
> 	From V4.1 protocol specification section 18.10.4. :
>
> 	"When one or more clients hold read delegations, any LOCK
request
> 	  where the server is implementing mandatory locking semantics,
MUST
> 	  result in the recall of all such delegations."
>
>
> 	I have following question for above statement.
>
> 	Why is the recall of read delegations necessary if the LOCK
requested 
> is a READ
> 	lock?
>
>
> 	regards,
>
> 	Sandeep
>
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4 at ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>


--
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/



_______________________________________________
nfsv4 mailing list
nfsv4 at ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4