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

[David Noveck <[e-mail]>]

It appears that you want an informational document saying, more or less:

   - If the server does not want clients to be discomfited by open files
   being removed, since such behavior is disallowed by typical OS (e.g.Unix)
   semantics, the server can avoid this situation by delaying the actual
   removal of the file until last close, as allowed by RFC7530.
   - The use of rename by clients as a substitute for remove, normally
   known as "silly rename", has significant problems, since removes can happen
   on nodes that do not have the file open.

If this is what you want, then you can write an I-D and submit it.

On Tue, Dec 13, 2016 at 1:17 PM, Marcel Telka <[e-mail]> wrote:

>
> Citát Trond Myklebust <[e-mail]>:
>
> On Tue, Dec 13, 2016 at 12:19 PM, Marcel Telka <[e-mail]> wrote:
>>
>>
>>> Citát Trond Myklebust <[e-mail]>:
>>>
>>>
>>> On Tue, Dec 13, 2016 at 11:56 AM, Marcel Telka <[e-mail]> wrote:
>>>
>>>>
>>>> Citát David Noveck <[e-mail]>:
>>>>
>>>>>
>>>>> And, ... what implementors do now with RFC 7530?  If they want to
>>>>> support
>>>>>
>>>>>>
>>>>>> the unix semantics they need to follow the note above albeit it is not
>>>>>>> written in the RFC.
>>>>>>>
>>>>>>>
>>>>>>> Some implementors already do this, and your note won't affect them.
>>>>>>
>>>>>> The problem is with those that don't.  Why would your note cause them
>>>>>> to
>>>>>> change course?  I think they will basically figure that clients are
>>>>>> going
>>>>>>
>>>>>>
>>>>>> My note will suggest them that if they want the unix semantics they
>>>>> will
>>>>> be clearly instructed what they need to implement.
>>>>>
>>>>>
>>>>> That's hilarious...
>>>>
>>>>
>>> Please elaborate.
>>>
>>>
>>> RFC7530 was never intended to serve as the basis for a new standard; it
>> was
>> an update of RFC3530 and was proposed solely in order to make the
>> description of the NFSv4 spec comply with the existing implementations.
>> The
>> main requirement was that we must not change the wire protocol unless
>> there
>> was mismatch between the spec and the implementations.
>>
>> Now you're asking for a change to a 13 year old protocol for which there
>> has not been a new implementation in almost a decade. Are you writing an
>> implementation of this change?
>>
>
> Sorry, but I probably didn't worded my mails properly.  And, unfortunately,
> I do not know what should I reword to make it more clear.  Please let me
> know
> what in my mails suggests you that I propose the wire protocol change.
> Thanks.
>
> In any case: I'm not asking for a protocol change (or at least it is not
> my intention). I'm asking for a note that won't change over the wire
> protocol
> at all.  It would just document the common practice used (and implemented)
> by many current NFSv4.0 servers (for example Linux NFS server).
>
> Yes, we recently found that illumos NFSv4.0 server does not follow this
> (maybe Solaris is same, I didn't tested) so the unix semantics is not
> supported
> there.  And yes, there is an attempt to implement it.
>
> And, please note that the implementation in Linux NFS server is not denied
> by
> the RFC 7530.  The suggested note won't change that.  The note just says:
>
> If you want a feature A, then you should implement B.  Where B is optional.
>
> A == unix semantics on NFS clients
> B == access to removed files via their file handle until the last CLOSE
>
> Currently, the RFC 7530 says:
>
> If you want, you can implement B.  Where B is optional.
>
>
> Thank you.
>
>
> --
> +-------------------------------------------+
> | Marcel Telka   e-mail:   [e-mail]  |
> |                homepage: http://telka.sk/ |
> |                jabber:   [e-mail] |
> +-------------------------------------------+
>
>