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

[David Noveck <[e-mail]>]

> Actually replying to a random thread, mostly Dave's...

The big element of randomness/confusion is whether the questions with
regard to delegations are posed with regard to NFSv4.0, in which the client
is doing silly rename, NFSv4.1 in which OPEN4_RESULT_PRESERVE_UNLINKED is
returned, or to a hypothetical extension in which silly
rename is disallowed/deprecated.

As a result, the handling of your scenario is going to have a big dose of
"it depends" but I'll try to clarify as well as I can.

> 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?)

In the case of v4.0, no.  However, if the client is doing silly rename,
then the RENAME may trigger a delegation recall.  A client could choose to
return the delegation in advance to forstall the need for a recall and
reduce latency.  After all, if you are removing a file, the consequent file
non-existence assures you that no other clients have it open and the
delegation might well be considered superfluous. YMMV.

In the case of OPEN4_RESULT_PRESERVE_UNLINKED, the situation is unclear.
The existing text is not clear as to whether the server's promise to retain
the inode as long as the file is open
applies in the case in which a delegation allows a client-local open to
exist.  If we decide to try to revitalize
OPEN4_RESULT_PRESERVE_UNLINKED (unlikely in my opinion), it needs to be
clear that the potential
existence of local open needs to be taken into account.  However, if this
is done it should be clear that there
is no requirement to promptly resolve the question of the existence of such
local opens.

With regard to a hypothetical replacement for OPEN4_RESULT_PRESERVE_UNLINKED,
the handling
should be the same.

> Or does a Delegation have the same effect as an Open against the file on
the server.

That's the way things should be, if the server is making the decision, but
but we are not there yet.


On Sun, Jan 1, 2017 at 6:19 PM, Rick Macklem <[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.
>
> rick
>
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
>