From: Noveck, Dave (Dave.Noveck@netapp.com)
Date: 09/22/00-10:44:12 AM Z
Message-ID: <641BC3DDCEB3D3118C3700902745938E01F6A533@BLACK>
From: "Noveck, Dave" <Dave.Noveck@netapp.com>
Subject: RE: Byte Range Locking, What's OK?
Date: Fri, 22 Sep 2000 08:44:12 -0700
> I'm implementing byte-range locking, and have decided to punt on
> the subrange issue (at least for now)
I see you're reserving the right to suddenly change your mind about
punting and run on fourth and long. I wouldn't be surprised to see
your server supporting subrange locking at the bake-off.
> and use this as my server's policy:
>
> In any case, servers or server file systems may not be able to
> support sub-range lock semantics. In the event that a server
> receives a locking request that represents a sub-range of current
> locking state for the lock owner, the server is allowed to return the
> error NFS4ERR_LOCK_RANGE to signify that it does not support sub-
> range lock operations.
>
>
> it's clear that in order to implement subrange locking, the possible subrange
> cases that dave has enumerated need to be addressed in the spec. is INVAL what
> applications expect as an error from subrange locking, or are there more
> informative error returns? LOCK_RANGE?
>From this paragraph, it appears that you believe the the
cases I enumerated are "subrange cases" while I would describe
them as "wierd cases which aren't subrange cases". If they are
indeed "subrange cases", then the according to the spec,
non-subrange-supporting servers should return LOCK_RANGE
sub-range supporting servers should just implement the request
I don't have any problem with this, but if this is the consensus,
the spec should make this clear.
The other interpretation, which is that my wierd cases are not
"subrange cases", which has at least as much support within the
spec, implies,
all servers should return INVAL for these cases
clients need to keep track of the locks that they hold and
use that information to determine how to simulate the wierd
(but non-subrange) cases.
>What I'm currently planning to do for the bake-off is to return
>INVAL for 1) through 6), but not 3a). Will there be (and also
>should there be) clients that expect some different behavior?
>>First unlock and upgrade are mentioned but downgrade is not. Since
>>downgrade of a subrange gives rise to the same atomicity issues
>>as unlock of a sub-range (if the client were to try to simulate it)
>>I'm assuming this is an oversight and that downgrade of a sub-range
>>(i.e. by getting a read lock of an area previously locked for write)
>>is OK, but the server may return a LOCK_RANGE error. Comments?
>that's how i read the spec - it's legal for the server to return
>LOCK_RANGE error on any subrange lock request.
Right but my main concern is with the other half of it: that servers
that do support sub-range semantics should supprot downgrade of a
subrange as well as upgrade and unlock.
This archive was generated by hypermail 2.1.2 : 03/04/05-01:48:17 AM Z CST