[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [nfsv4] Read delegations and LOCK operation
On Wed, October 28, 2009 4:03 pm, Noveck, Dave wrote:
>> ... 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.
Or the system implicitly locks the range on behalf of the process,
and unlocks it after the I/O is done. That's how System V did it, and
I suspect Windows does it. The NFSv4.0 and NFSv4.1
specs discuss this.
>
> 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.
Yes, we are saying the same thing, provided you add that while the
IO is in progress, another process or client cannot get a conflicting
mandatory lock on the byte range of the I/O.
>
> 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.
Agreed. I don't claim to 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
>
--
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/