Re: [nfsv4] RFC 7530: Filehandle of opened file after the REMOVE

[Trond Myklebust <[e-mail]>]

> On Jan 2, 2017, at 15:26, David Noveck <[e-mail]> wrote:
> 
> > See:
> > https://tools.ietf.org/html/rfc7530#section-10.4.4 <https://tools.ietf.org/html/rfc7530#section-10.4.4>
> 
> Thanks.
> 
> > Note that the above special case appears only to apply to _directories_. It is not qualifying the “RENAME request for the file as either source or target…”.
> 
> I got confused about this.  I think I somehow conflated this with the material in the bulleted items in Section 16.26.5.  I somehow assumed that the text would indicate that a delegation allowing local opens would have to be recalled to enable the server to determine whether the directory "SHOULD NOT" or "SHOULD" be deleted.  THere is no such  text in RFC7530 now, but I'm not sure what to do about that.
> 
> >There is also https://tools.ietf.org/html/rfc7530#section-10.4 <https://tools.ietf.org/html/rfc7530#section-10.4>
> 
>    When a single client holds an OPEN_DELEGATE_READ delegation, it is
>    assured that no other client may modify the contents or attributes of
>    the file.  If more than one client holds an OPEN_DELEGATE_READ
>    delegation, then the contents and attributes of that file are not
>    allowed to change.  When a client has an OPEN_DELEGATE_WRITE
>    delegation, it may modify the file data since no other client will be
>    accessing the file's data.  The client holding an OPEN_DELEGATE_WRITE
>    delegation may only affect file attributes that are intimately
>    connected with the file data: size, time_modify, and change.
> 
> > That last sentence implies (but does not state explicitly) that the client must give up the write delegation 
> > if it wants to modify other file attributes.
> 
> I don't think that was the intention, although I can see how it might be read that way.
> 
> I read this as saying that the client holding a WRITE delegation may only affect those data-related attributes locally since it has a guarantee that no other clients are looking at them (and that CB_GETATTR will be used when appropriate).  Other attributes (including named attributes which are not explicitly included or excluded) are outside the scope of the delegation.  I don't see that a client holding a WRITE delegation has to give it back simple because he is changing some other attribute.  I think he can do the SETATTR normally in this case.  I also note that section 10.4.4. says "SETATTR issued by another client", suggesting that one issued by the client holding the delegation is OK.
> 
> 
> > https://tools.ietf.org/html/rfc5661#section-10.4.4 <https://tools.ietf.org/html/rfc5661#section-10.4.4>
> 
> It is Section 10.4.4 in both 7530 and 5661.  Coincidence ... or
> something else? :-)
> 
> 
> >The text in RFC7530 was a straight cut n’ paste job from RFC5661
> 
> It appears that RFC5661 was a cut n' paste from RFC3530, so it isn't
> clear whether the RFC7530 text was derived from RFC3530 (which makes
> sense)  or from RFC5661, which doesn't, since v4.0 and v4.1 are different
> protocols.
> 
> The problem is the inappropriate cut n' paste from RFC3530 to RFC5661.
> It appears that this was a mistake although I don't think we can deal with this 
> via an errata.  It is worth noting that the list in question is introduced by the 
> the non-RFC2119 phrase "The following events necessitate the recall 
> of an open delegation”.

I fully agree that looks at first glance as if it is a non-normative text. Unfortunately, 15 years of server implementations have taken it as gospel, and hence no client that cares about performance can afford to ignore it.

> 
> On Mon, Jan 2, 2017 at 7:52 AM, Trond Myklebust <[e-mail] <mailto:[e-mail]>> wrote:
> 
>> On Jan 2, 2017, at 13:11, David Noveck <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> > If you read RFC7530, then the client is expected to return the delegation before doing any form of RENAME or REMOVE
>> 
>> Could you be more specific about where you saw that?  I tried to find it but didn't succeed.  In fact, with regard to RENAME, the text makes the need for a recall conditional about whether the server in question might disallow RENAMEs depending on what existing opens deny.  I don't remember any statement about expectations regarding delegation return in advance of these ops.
> 
> See:
> https://tools.ietf.org/html/rfc7530#section-10.4.4 <https://tools.ietf.org/html/rfc7530#section-10.4.4>
> 
> 10.4.4 <https://tools.ietf.org/html/rfc7530#section-10.4.4>.  Recall of Open Delegation
> 
>    The following events necessitate the recall of an open delegation:
> 
>    o  Potentially conflicting OPEN request (or READ/WRITE done with
>       "special" stateid)
> 
>    o  SETATTR issued by another client
> 
>    o  REMOVE request for the file
>    o  RENAME request for the file as either source or target of the
>       RENAME
> 
>    Whether a RENAME of a directory in the path leading to the file
>    results in the recall of an open delegation depends on the semantics
>    of the server file system.  If that file system denies such RENAMEs
>    when a file is open, the recall must be performed to determine
>    whether the file in question is, in fact, open.
> 
> Note that the above special case appears only to apply to _directories_. It is not qualifying the “RENAME request for the file as either source or target…”.
> 
> There is also https://tools.ietf.org/html/rfc7530#section-10.4 <https://tools.ietf.org/html/rfc7530#section-10.4>
> 
>    When a single client holds an OPEN_DELEGATE_READ delegation, it is
>    assured that no other client may modify the contents or attributes of
>    the file.  If more than one client holds an OPEN_DELEGATE_READ
>    delegation, then the contents and attributes of that file are not
>    allowed to change.  When a client has an OPEN_DELEGATE_WRITE
>    delegation, it may modify the file data since no other client will be
>    accessing the file's data.  The client holding an OPEN_DELEGATE_WRITE
>    delegation may only affect file attributes that are intimately
>    connected with the file data: size, time_modify, and change.
> 
> That last sentence implies (but does not state explicitly) that the client must give up the write delegation if it wants to modify other file attributes.
> 
>> 
>> > since the server has no stateid or session id with which to identify the origin of the RPC call.
>> 
>> True statement about an annoying aspect of v4.0, but I'm not clear about where it appears in RFC7530.
> 
> It doesn’t, but that was the main argument for recalling the delegation in the cases.
> 
>> 
>> > It is less obvious that this needs be the case for NFSv4.x (x>0), but I can't remember seeing any changes to those texts in RFC5661.
>> 
>> Once we find the text in RFC7530, we can address RFC5661.  If the text you recall seeing in RFC7530 appears unchanged in RFC5661, we might need an errata.
>> 
> 
> 
> https://tools.ietf.org/html/rfc5661#section-10.4.4 <https://tools.ietf.org/html/rfc5661#section-10.4.4>
> 
> 
> The text in RFC7530 was a straight cut n’ paste job from RFC5661.
> 
>> 
>> On Sun, Jan 1, 2017 at 6:36 PM, Trond Myklebust <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 
>> On 2 January 2017 at 00:19, Rick Macklem <[e-mail] <mailto:[e-mail]>> wrote:
>> Tom Talpey wrote:
>> On 1/1/2017 8:13 AM, David Noveck wrote:
>> > Btw, my preferred title for such a document, almost certain to be
>> > rejected, is "Silly Rename Must Die" :-)
>> Actually replying to a random thread, mostly Dave's...
>> 
>> A case that I wasn't clear on w.r.t. this is:
>> - The client holds a delegation for the file.
>> - The client issues opens locally w.r.t. this delegation.
>> - A process/thread on the client does a "Remove" of the file.
>> 
>> Is the client expected to acquire Opens against the server and return the
>> Delegation? (This seems like more work than just doing good old sillyrename?)
>> - Or does a Delegation have the same effect as an Open against the file on the
>>   server.
>> 
>> If you read RFC7530, then the client is expected to return the delegation before doing any form of RENAME or REMOVE, since the server has no stateid or session id with which to identify the origin of the RPC call.
>> 
>> It is less obvious that this needs be the case for NFSv4.x (x>0), but I can't remember seeing any changes to those texts in RFC5661.
>> 
>> Cheers
>>   Trond
>> 
>> _______________________________________________
>> nfsv4 mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/nfsv4 <https://www.ietf.org/mailman/listinfo/nfsv4>
>> 
>> 
> 
>