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

Marcel Telka <marcel@telka.sk> Tue, 13 December 2016 18:17 UTC

Return-Path: <marcel@telka.sk>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E74A129481 for <nfsv4@ietfa.amsl.com>; Tue, 13 Dec 2016 10:17:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.796
X-Spam-Level:
X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBzqN_8vuah5 for <nfsv4@ietfa.amsl.com>; Tue, 13 Dec 2016 10:17:38 -0800 (PST)
Received: from tortuga.telka.sk (tortuga.telka.sk [185.14.234.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62D421293E9 for <nfsv4@ietf.org>; Tue, 13 Dec 2016 10:17:37 -0800 (PST)
Received: (qmail 5407 invoked from network); 13 Dec 2016 18:17:34 -0000
Received: from localhost (HELO tortuga.telka.sk) (127.0.0.1) by localhost with SMTP; 13 Dec 2016 18:17:34 -0000
Received: from tyhog-gua01a-216.cronon.net (tyhog-gua01a-216.cronon.net [192.166.200.216]) by mail.telka.sk (Horde Framework) with HTTPS; Tue, 13 Dec 2016 18:17:34 +0000
Date: Tue, 13 Dec 2016 18:17:34 +0000
Message-ID: <20161213181734.Horde.EqgB09El8rupnkesIQaBwJ3@mail.telka.sk>
From: Marcel Telka <marcel@telka.sk>
To: Trond Myklebust <trondmy@gmail.com>
References: <20161209222500.GB1514@telcontar> <CADaq8jck1P2vcDZjaFSnQRFYUnAyjJCqDgxqdWPDhEjPP7hDmA@mail.gmail.com> <20161213113547.Horde.wCZotJjSqGlvU03mq8Ptel3@mail.telka.sk> <CADaq8je40Siv5r9r2gd8b+n4P_qeueBpxuASTsaQLHV5jca7yA@mail.gmail.com> <20161213155825.Horde.vsqZuNSZ9hIXlcHQYxmgRC7@mail.telka.sk> <CADaq8jeiwGwgV=_HHjR2D4uNaKq9zY96hJOVXp4Q0H-3OgH2qA@mail.gmail.com> <20161213165639.Horde.t6BGVBJqifWKHucfa069yT8@mail.telka.sk> <CAABAsM579kGU4VzZfqWPUMPJ14QDBheJ8eMAk7DrYUSGscfVkQ@mail.gmail.com> <20161213171902.Horde.MkS1YMOM6VpxA0Z7rSMTe7P@mail.telka.sk> <CAABAsM5L0xdKodxk1dRSugLyROzn2JzgDkq6kdHE0LuGcfh++A@mail.gmail.com>
In-Reply-To: <CAABAsM5L0xdKodxk1dRSugLyROzn2JzgDkq6kdHE0LuGcfh++A@mail.gmail.com>
User-Agent: Horde Application Framework 5
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
MIME-Version: 1.0
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/Yblz1mL6zs0Yx25VGeju3uabmt4>
Cc: nfsv4@ietf.org
Subject: Re: [nfsv4] RFC 7530: Filehandle of opened file after the REMOVE
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Dec 2016 18:17:41 -0000

Citát Trond Myklebust <trondmy@gmail.com>om>:

> On Tue, Dec 13, 2016 at 12:19 PM, Marcel Telka <marcel@telka.sk> wrote:
>
>>
>> Citát Trond Myklebust <trondmy@gmail.com>om>:
>>
>>
>> On Tue, Dec 13, 2016 at 11:56 AM, Marcel Telka <marcel@telka.sk> wrote:
>>>
>>> Citát David Noveck <davenoveck@gmail.com>om>:
>>>>
>>>> And, ... what implementors do now with RFC 7530?  If they want to support
>>>>>
>>>>>> the unix semantics they need to follow the note above albeit it is not
>>>>>> written in the RFC.
>>>>>>
>>>>>>
>>>>> Some implementors already do this, and your note won't affect them.
>>>>>
>>>>> The problem is with those that don't.  Why would your note cause them to
>>>>> change course?  I think they will basically figure that clients are
>>>>> going
>>>>>
>>>>>
>>>> My note will suggest them that if they want the unix semantics they will
>>>> be clearly instructed what they need to implement.
>>>>
>>>>
>>> That's hilarious...
>>>
>>
>> Please elaborate.
>>
>>
> RFC7530 was never intended to serve as the basis for a new standard; it was
> an update of RFC3530 and was proposed solely in order to make the
> description of the NFSv4 spec comply with the existing implementations. The
> main requirement was that we must not change the wire protocol unless there
> was mismatch between the spec and the implementations.
>
> Now you're asking for a change to a 13 year old protocol for which there
> has not been a new implementation in almost a decade. Are you writing an
> implementation of this change?

Sorry, but I probably didn't worded my mails properly.  And, unfortunately,
I do not know what should I reword to make it more clear.  Please let me know
what in my mails suggests you that I propose the wire protocol change.  
  Thanks.

In any case: I'm not asking for a protocol change (or at least it is not
my intention). I'm asking for a note that won't change over the wire protocol
at all.  It would just document the common practice used (and implemented)
by many current NFSv4.0 servers (for example Linux NFS server).

Yes, we recently found that illumos NFSv4.0 server does not follow this
(maybe Solaris is same, I didn't tested) so the unix semantics is not  
supported
there.  And yes, there is an attempt to implement it.

And, please note that the implementation in Linux NFS server is not denied by
the RFC 7530.  The suggested note won't change that.  The note just says:

If you want a feature A, then you should implement B.  Where B is optional.

A == unix semantics on NFS clients
B == access to removed files via their file handle until the last CLOSE

Currently, the RFC 7530 says:

If you want, you can implement B.  Where B is optional.


Thank you.

-- 
+-------------------------------------------+
| Marcel Telka   e-mail:   marcel@telka.sk  |
|                homepage: http://telka.sk/ |
|                jabber:   marcel@jabber.sk |
+-------------------------------------------+