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

[Trond Myklebust <[e-mail]>]

On Wed, Dec 14, 2016 at 6:21 AM, Marcel Telka <[e-mail]> wrote:

> Citát 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.
>>
>
> Yes, this is exactly what I want to see.
>
>
There are 4 main problems that are inadequately discussed in any of the
existing RFCs, and that you need to address before we can consider
replacing sillyrename (which is well established today, and well understood
by most users).

1) How does the client identify that the server supports this functionality?
2) What functionality is needed on the underlying filesystems on the server?
3) How does the server function in the case of a reboot? What can the
client expect in terms of recoverability?
4) How does the client in practice perform recovery?
   a) In the case of server reboots.
   b) In the case of lease timeouts/network partitions

Note that the lack of open-by-filehandle in NFSv4.0 makes 4.b) more
difficult than it should otherwise be.