[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [nfsv4] Read delegations and LOCK operation
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
> >
>
>