[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [nfsv4] Read delegations and LOCK operation
Yes, but that's really because we also ignore the 'rflags' OPEN result.
I should really have us fail all file locking attempts on servers that
do not return the OPEN4_RESULT_LOCKTYPE_POSIX flag on OPEN. We're simply
not prepared to deal with non-posix locking semantics...
Cheers
Trond
On Wed, 2009-10-28 at 16:06 -0700, Mike Eisler wrote:
> > 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
> >> >
> >>
> >>
> >
> >
> >
>
>