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

[David Noveck <[e-mail]>]

> I'm late, I know.

I guess I can't resist a (barely) relevant movie quote, from *The Big
Short:*

Dr. Michael Burry:  I may have been early, but I'm not wrong.

Martin Blaine: It's the same thing!

You're late with this but there would have been no way that you could have
been on time.
If you raised this issue in time for RFC3530, I don't think anyone would
have listened to
you.  You could have stuck to your position, made yourself very unpopular
and
prevented NFSv4 from happening.

RFC3530, RFC7530, RFC 5661 are immutable.  The only way they can be changed
is
via errata, and your judgment, that we made the wrong choice here is not a
good basis
for one.

I think this could be addressed in NFSv4 going forward via an extension.

On Tue, Dec 13, 2016 at 6:35 AM, Marcel Telka <[e-mail]> wrote:

> Citát David Noveck <[e-mail]>:
>
>> The above clearly says that for clientB the filehandle for the file
>>> after the REMOVE operation MAY be valid.
>>>
>>
>> As I read it, it MAY be either valid or invalid and this applies to
>> validity as perceived by any client.
>>
>> The clientB just removed the file, so it should not be surprised
>>> the filename (obtained in step 2) is no longer valid.
>>>
>>
>> He shouldn't, but if he was a stickler for unix semantics, he would have a
>> problem.
>>
>
> I think all unix NFS clients usually expect the unix semantics.
> They definitely do so (at least) for their local files...
>
>
>> What is unclear to me is clientA.  Is it okay for the server to
>>> 'forget' the filehandle even for clientA?
>>>
>>
>> It is allowed by the spec.
>>
>> If the filehandle won't be valid for clientA (after the REMOVE
>>> by clientB), then clientA might lost the access to the file anytime, >
>>>
>> and it have no easy chance to prevent that (and no way to recover > from
>> that).
>>
>> This sounds unfortunate and it breaks the traditional unix
>>> semantics: the file is there while I hold it opened.
>>>
>>
>> True but people have been OK with this for two reasons:
>>
>>    1. Most clients will implement NFSv3 sillyrename which is alluded to in
>>    the paragraph above the bulltets you quote.  Interestingly, it is a
>>    "should" rather than a "SHOULD", since interoperability is not
>> affected.
>>
>
> The paragraph you are referring to is copied (almost verbatim)
> from RFC 1813, section 3.3.12.  Unfortunately.  I would prefer to do not
> have it here and instead require the server to allow access to the removed
> file until the last close.  I'm late, I know.
>
>    2. In the case of other clients, NFS users may have have been bringing
>>    expectations formed on the basis of experiences with NFSv3, and from an
>>    NFSv3 perspective, this server behavior is unexceptionable.
>>
>
> Yes, but from the NFSv3 perspective the NFSv4 is not needed at all :-).
>
> Maybe we should add a note that "if the server wants to support the unix
> semantics (a removed file is accessible until the last close) then the
> continued access to the file via its file handle until the last
> CLOSE is essential".
>
>
>>
>> A possible extension to NFSv4.2 could provide an attribute to allow the
>> client to determine how the server dealt with this issue.
>>
>
> Either that, or just the note I suggested above.  Or even better: both.
>
> Please note that without the continued access to the file via its file
> handle until the last CLOSE there seems to be no way how to reliably
> implement the unix semantics for NFS clients.  And no, the sillyrename
> is not the answer, because if it is, then all clients would need to
> create a silly name for every opened file to make sure no other client
> (or even a local process at the server) will remove their file while
> it is still open by them.  The other problem with this approach
> would be: how to prevent other clients to remove my silly name?
>
>
>> The only way to make sure the file is available until the final
>>> CLOSE seems to be to open the file with
>>> OPEN4_SHARE_DENY_WRITE or
>>> OPEN4_SHARE_DENY_BOTH,
>>>
>>
>> I'm don't think you can be sure of this, since
>>
>>    1. In speaking of the directory entry it only says "SHOULD NOT"
>>
>
> True.  I misinterpreted SHOULD NOT as SHALL NOT.
>
>    2. The text doesn't say explicitly that processing should stop at this
>>    point, with an error returned.
>>    3. there seems to be no text at all regarding continued access to the
>>    file by existing opens in the DENY case.  This may need some sort of
>>    correction but I'm not sure at this point exactly what sort of
>> correction
>>    we could put in, given the need to be compatible with all existing
>>    implementations.
>>
>>
>> which sounds like overkill.
>>>
>>
>> Not exactly:
>>
>>    1. It prevents stuff you don't want to prevent
>>    2. It is not guaranteed to prevent what you really want to prevent.
>>
>>
>> Am I overlooking something?
>>>
>>
>> I think you are overlooking sillyrename.
>>
>
> Unfortunately, the sillyrename works only for the client that currently
> have the file opened.  If the client is removing a file it does not have
> opened, it does not do the sillyrename (at least the clients I'm
> working with does not do so).
>
>
>> In your example either or both of A and B might by implementing
>> silllyrename and it isn't clear how things would work if both A and B did.
>> :-(
>>
>
> In my example the clientA have no reason to implement the silllyrename
> because it didn't removed the file.
>
>
>> I think it would help if we considered this issue in historical context.
>> Making NFSv4 stateful was a wrenching change and it is not surprising if
>> we
>> have adapted to that change incompletely.  Some of the IESG commentary
>> about RFC3530 expressed reserve or uncertainty (although no actual
>> objection) about making this change, saying essentially "Well if you guys
>> *really* want to do this, OK".
>>
>
>
> Thank you.
>
> --
> +-------------------------------------------+
> | Marcel Telka   e-mail:   [e-mail]  |
> |                homepage: http://telka.sk/ |
> |                jabber:   [e-mail] |
> +-------------------------------------------+
>
>