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

[Marcel Telka <[e-mail]>]

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] |
+-------------------------------------------+