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

On Wed, Dec 14, 2016 at 09:28:41AM -0500, Trond Myklebust wrote:
> On Wed, Dec 14, 2016 at 6:21 AM, Marcel Telka <marcel@telka.sk> wrote:
> 
> > Citát David Noveck <davenoveck@gmail.com>:
> >
> >> 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?

I think this is what OPEN4_RESULT_PRESERVE_UNLINKED in 5661 was meant to
do.  It'd be interesting to try an implementation and see if your other
points are addressed, but I haven't thought about it in a long time.

--b.

> 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.

> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4