[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [nfsv4] Read delegations and LOCK operation
> The Windows 2000 client will just have to wait if it decides to try to
> set a write lock on a file which it opened for read only.
It won't necessarily have to wait.
If the non-Linux/non-Windows client and server are following
a different semantic such as an advisory exclusive byte lock
is allowed on a file open for READ, then the server will grant the lock
despite the delegation on the Linux client. Then later, when the
Linux client flushes its conflicting byte range shared lock on the file,
the LOCKU will fail because the non-Linux/non-Windows client has the
lock. That's what the Linux client gets for failing to honor:
>> "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.
>> "
:-)
This is somewhat theoretical, but there are lots of systems that
don't follow POSIX or Windows (such as the various IBM operating systems),
and possibly their semantics are such that clients and servers that
don't follow the above will get burned.
On Wed, October 28, 2009 3:04 pm, Trond Myklebust wrote:
> FWIW the Linux client will completely ignore this rule, and will cache
> read locks as long as it holds a read or a write delegation.
>
> The Windows 2000 client will just have to wait if it decides to try to
> set a write lock on a file which it opened for read only.
>
> Cheers
> Trond
>
> On Wed, 2009-10-28 at 14:10 -0700, Mike Eisler wrote:
>> 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/