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

David Noveck <davenoveck@gmail.com> Tue, 13 December 2016 16:21 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 6E448129BB5 for <nfsv4@ietfa.amsl.com>; Tue, 13 Dec 2016 08:21:44 -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 EHcOqqEJvBNi for <nfsv4@ietfa.amsl.com>; Tue, 13 Dec 2016 08:21:33 -0800 (PST)
Received: from mail-oi0-x242.google.com (mail-oi0-x242.google.com [IPv6:2607:f8b0:4003:c06::242]) (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 86D5E129BB8 for <nfsv4@ietf.org>; Tue, 13 Dec 2016 08:20:42 -0800 (PST)
Received: by mail-oi0-x242.google.com with SMTP id u15so16012407oie.3 for <nfsv4@ietf.org>; Tue, 13 Dec 2016 08:20:42 -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=yC/oTnOT0+qJ57PHq7tIku0olB11tmkDWiAbWEjCzxM=; b=k8op0ZMxstetoQkO5Jwe/U5RnHXFvDxSXi3ynHp9ZGHjBVcLoQN4GtfEJsaelbEiw9 xYffj09JHKDoeKzh3UzG6tjuROe3WesZjY3g5YkdAToxYBwuuxdyLNWRuBrIB3ZdRTPT 3o0nj+ZjTf54WnnFfCJXxT4MyrqdG2Xeb3Cva+LgqPWPzMru9w/xSDK1VynTAHPpWWOL UW0zmUJWspJdhO+7P/cNK51JYEzd+tMvAR4oxA36E0KFnzHPhgfvF8s02/dqk62mUruq v77MXrq/nzgBSnrd4mxohQvGxyqZ3HynnuHjMiY6CvM37i9uuzr/G806Nlmwy7ViUHB4 ITjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yC/oTnOT0+qJ57PHq7tIku0olB11tmkDWiAbWEjCzxM=; b=FpYNqDj3DC5TVvqJcRmMF/RxsvF3VnyzzhEeBbXsBXMGpepFiv4LQWBYmvuMgUWPNF 3rZkvQUqOxtKkcT6x/bcV7lOYZF1QpoYdIGZUx7X2ljbjgnKVM5UTVt/rqDOZLV4uUk4 CI11hLPAa3HVOm5ztxFCRm66sCh1cYgCM0MQYVosH/M/I/LaRyeOgcOBwUDywJ3JjRRl 2G21zwhxpbVmswYAF4nc1JgOG/Mol1iMplzAZPXG+dUfFEJ65coFXsLbhm45g0HWJipF vyxSou2Ao2+OJG9TMaHsvc1TpN9bgu2Q4PVeLPCbd8kFBsU9fRUuOXuZWa74Eww1byRj 70rg==
X-Gm-Message-State: AKaTC02Nn7qV1ly4n46CMeTSzq21acSW7/fTDu7a0vNBbUhk1IkYRMUxm5kQwIX1CYa718f57B3zK8l3T45wLQ==
X-Received: by 10.202.71.207 with SMTP id u198mr48022139oia.165.1481646041902; Tue, 13 Dec 2016 08:20:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.137.202 with HTTP; Tue, 13 Dec 2016 08:20:41 -0800 (PST)
In-Reply-To: <20161213155825.Horde.vsqZuNSZ9hIXlcHQYxmgRC7@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>
From: David Noveck <davenoveck@gmail.com>
Date: Tue, 13 Dec 2016 11:20:41 -0500
Message-ID: <CADaq8jeiwGwgV=_HHjR2D4uNaKq9zY96hJOVXp4Q0H-3OgH2qA@mail.gmail.com>
To: Marcel Telka <marcel@telka.sk>
Content-Type: multipart/alternative; boundary=001a113e574e02b55a05438c9a9c
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/aJbPcwRTj75fNS8ejM3TmpisD6k>
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: Tue, 13 Dec 2016 16:21:44 -0000

> 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
to do
a silly rename anyway, so they don't have to bother changing their code.

The problem is that NFSv3 made this a client responsibility and NFSv4,0 left
things as they were.  This is not just an issue for Unix.  Making sure an
open file
is not removed out from under the client is a good thing for other OS's as
well.


On Tue, Dec 13, 2016 at 10:58 AM, Marcel Telka <marcel@telka.sk> wrote:

> Citát David Noveck <davenoveck@gmail.com>om>:
>
>> 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
>>
>
> RFC 3530 is maybe immutable, but also obsoleted, so nobody cares
> about it much these days. :-)
>
> Similarly as nobody cares about RFC 3010 now.
>
> is
>> via errata, and your judgment, that we made the wrong choice here is not a
>> good basis
>> for one.
>>
>
> No, I do not suggest that the choice made was wrong.  The current wording
> allows to implement (maybe) simpler NFSv4 servers that do not need to
> bother
> with preserving file handles after the REMOVE (if they do not worry about
> unix).  This is good.
>
>
>> I think this could be addressed in NFSv4 going forward via an extension.
>>
>
> Why not to use the note I suggested (properly rephrased, of course) even
> for RFC 7530 (as errata)?
>
> This one:
>
> "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."
>
> It won't change this (or anything else in RFC 7530, AFAIK):
>
>    o  If the file was not opened with OPEN4_SHARE_DENY_WRITE or
>       OPEN4_SHARE_DENY_BOTH, the server SHOULD delete the file's
>       directory entry.  However, until the last CLOSE of the file, the
>       server MAY continue to allow access to the file via its
>       filehandle.
>
> It will just add a note (or recommendation, suggestion, clarification,
> whatever) for implementors who want to make sure their NFSv4 servers
> are properly prepared to support the unix semantics for NFSv4 clients.
>
> 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.
>
>
> Thanks.
>
>
> --
> +-------------------------------------------+
> | Marcel Telka   e-mail:   marcel@telka.sk  |
> |                homepage: http://telka.sk/ |
> |                jabber:   marcel@jabber.sk |
> +-------------------------------------------+
>
>