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

David Noveck <davenoveck@gmail.com> Wed, 14 December 2016 10:56 UTC

Return-Path: <davenoveck@gmail.com>
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 0A7D0129A45 for <nfsv4@ietfa.amsl.com>; Wed, 14 Dec 2016 02:56:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 pmhMqaNX1U0i for <nfsv4@ietfa.amsl.com>; Wed, 14 Dec 2016 02:56:26 -0800 (PST)
Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98EBC1295A7 for <nfsv4@ietf.org>; Wed, 14 Dec 2016 02:56:03 -0800 (PST)
Received: by mail-oi0-x22d.google.com with SMTP id b126so16243132oia.2 for <nfsv4@ietf.org>; Wed, 14 Dec 2016 02:56:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ert8wTEOF6L73IkqN0tyIXg7jAF9jj4QXw+fqsyM1TQ=; b=ea1CAIov3mafo8Aj3KT1jTfzW6WZHzWU9rtbbZUkqU26JjPaB1RA1Zc1M7DmdzSoHV E9yWA0DdEN2peovXIHPcPfzwaASiU9Xu0rcgB+hrcNjENKjUYwXBBXvsJvK7xDoFvkSf cRTqkbjDpFDDxXOHbO49yWpM4Db/HKGYTPi0djTU1POtxvNHhSa2RMPM7KD5tWZC6Xka laeisQlFOhI98D9TzUnZWPXTc+4brm7VaXEaBoqvJBLhVYbXAUnwL0F/p0ARqhDqOt7A n7cFggOVOIkTzLHWPrnmvTG1ve9M8/ApraTaOd9dV7G/u0/Wp3TC/d8n1OQvnF6QhrCp 3x/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ert8wTEOF6L73IkqN0tyIXg7jAF9jj4QXw+fqsyM1TQ=; b=T2lowFQetdRqE9vvSKjL1lKMoHx2DvK7l//IBcNQhya6SHIIPj60VcGrOE8DMcJSHH MivqrDGGgeH2HZ2EAX326gE329BGbfRFO/70j9W/J40OdNeAtegcBNHycvU+BhHpewby gBw9n8ibKD10yF5OcMbDcUM1MKQ4WSHy62CIwJHD5Mzbk3mx/x6LlVXv+NgJRDZmyxiF +yKhU1QpLVQ9hYGaunUApE1GrPYLEH89blHFqMebCnG9ZbRTRDU9IQqlnfbyKzzmoU2r wtN7p4pPv0t9e7/kwKp8tcIH9oo0ECCByRwYw3lBXX82mtQMbob+LT/2h8iqCfPvwRYb N9Jw==
X-Gm-Message-State: AKaTC03HjFcNWPSwl7GfQH7W4z+XlkSW54TnDNFfoPogjPzcYPcal/l9sJf5+l7M18sxExKr/AwrJn7kTOpzyQ==
X-Received: by 10.157.51.53 with SMTP id f50mr54412898otc.34.1481712962944; Wed, 14 Dec 2016 02:56:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.137.202 with HTTP; Wed, 14 Dec 2016 02:56:02 -0800 (PST)
In-Reply-To: <20161213181734.Horde.EqgB09El8rupnkesIQaBwJ3@mail.telka.sk>
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> <20161213181734.Horde.EqgB09El8rupnkesIQaBwJ3@mail.telka.sk>
From: David Noveck <davenoveck@gmail.com>
Date: Wed, 14 Dec 2016 05:56:02 -0500
Message-ID: <CADaq8jcq2C0o8EWXoGjxDn58sV_J+-SP-=rj934Se-DV69b-pw@mail.gmail.com>
To: Marcel Telka <marcel@telka.sk>
Content-Type: multipart/alternative; boundary=001a1141ba08d0c54b05439c2ed8
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/l7L0SDzqMmGzndCU2vpbev0IXLE>
Cc: "nfsv4@ietf.org" <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: Wed, 14 Dec 2016 10:56:32 -0000

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.

On Tue, Dec 13, 2016 at 1:17 PM, Marcel Telka <marcel@telka.sk> wrote:

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