1 Jul 2011 02:10
Re: LOCK and locker
Rick Macklem <rmacklem <at> uoguelph.ca>
2011-07-01 00:10:28 GMT
2011-07-01 00:10:28 GMT
Trond Myklebust wrote: > On Thu, 2011-06-30 at 10:57 -0400, david.noveck <at> emc.com wrote: > > That's one of them. The other is that the lokowner information has > > to stay around even past CLOSE. > > I don't understand this statement. > > * There is already language in RFC3530 that describes how the > server should deal with a LOCKU replay after CLOSE. > * We definitely don't want to allow a new LOCK request using an > old lock stateid after CLOSE. > > So what is the point of keeping the lockowner after CLOSE, and where > is > the text that says we need to do so? > I just read Sec. 8.1.7 (of rfc3530) and it seems to say "may" be released. (And David, my appologies, I see it does define lock_owner, although the definition is a bit confusing to me because it uses the term for both open and byte range locks.) However, I agree with Trond in that I don't see a reason to keep it around after the Close. Note that, for an open_owner4 string, when the server sees one that it still has, but the client uses a different open_seqid#, it uses this open_seqid# as the new initial value and requires an OpenConfirm to verify that it should be the new one and this isn't an out of order replay. (When all the open stateids for the open_owner4 string have been Closed.)(Continue reading)
.
It looks like the change is confined to one paragraph, in section 18.42.3 of RFC 5661:
OLD
The LAYOUTCOMMIT operation commits changes in the layout represented
by the current filehandle, client ID (derived from the session ID in
the preceding SEQUENCE operation), byte-range, and stateid. Since
layouts are sub-dividable, a smaller portion of a layout, retrieved
via LAYOUTGET, can be committed. The byte-range being committed is
specified through the byte-range (loca_offset and loca_length). This
byte-range MUST overlap with one or more existing layouts previously
granted via LAYOUTGET (Section 18.43), each with an iomode of
LAYOUTIOMODE4_RW. In the case where the iomode of any held layout
segment is not LAYOUTIOMODE4_RW, the server should return the error
NFS4ERR_BAD_IOMODE. For the case where the client does not hold
matching layout segment(s) for the defined byte-range, the server
should return the error NFS4ERR_BAD_LAYOUT.
NEW
The LAYOUTCOMMIT operation commits changes in the layout represented
by the current filehandle, client ID (derived from the session ID in
the preceding SEQUENCE operation), and stateid. As a layout-independent
operation, LAYOUTCOMMIT commits the entire layout; layout-specific data
(loca_layoutupdate) may specify a layout subset that requires layout-
Having straightened that out.
Why add language specific to 5663 or other non-file layout types
in 5661? If special handling is needed, presumably it is in the
context of the layout type and can be captured in the RFC for
that layout type. Therefore, shouldn't the 5661 update be more
generic and then make it clear that additional MUST/SHOULD handling
of LAYOUTCOMMIT will be captured in 5663, etc.?
Spencer
> -----Original Message-----
> From: nfsv4-bounces <at> ietf.org [mailto:nfsv4-bounces <at> ietf.org] On Behalf Of
> david.black <at> emc.com
> Sent: Tuesday, July 05, 2011 2:14 PM
> To: spencer.shepler <at> gmail.com; thomas <at> netapp.com
> Cc: nfsv4 <at> ietf.org
> Subject: Re: [nfsv4] Quebec and LAYOUT_COMMIT
>
> That's a completely separate and distinct issue.
>
> Thanks,
> --David
>
>
> > -----Original Message-----
> > From: Spencer Shepler [mailto:spencer.shepler <at> gmail.com]
RSS Feed