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