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

David Noveck <davenoveck@gmail.com> Mon, 02 January 2017 11:54 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 0ECB412953D for <nfsv4@ietfa.amsl.com>; Mon, 2 Jan 2017 03:54:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, 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 U0unDIYztkQ8 for <nfsv4@ietfa.amsl.com>; Mon, 2 Jan 2017 03:54:38 -0800 (PST)
Received: from mail-oi0-x244.google.com (mail-oi0-x244.google.com [IPv6:2607:f8b0:4003:c06::244]) (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 12558126579 for <nfsv4@ietf.org>; Mon, 2 Jan 2017 03:54:38 -0800 (PST)
Received: by mail-oi0-x244.google.com with SMTP id u15so66128224oie.3 for <nfsv4@ietf.org>; Mon, 02 Jan 2017 03:54:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Q5KSnTkRxPQF9m8mE9dU1JUZeNwtdvELgrsRPQEAzOc=; b=Y5mAhmrv9MIq1rurztZIqaEtB/FduIr8nrxApIO9Aj7FVvBCBpGi5FOOUiJEeDj90B OoCCaqmbuI/EMEtQxzLfhErK+6VlmTYEMBJCX0iaAmVDuz7fjgzzt2wNoTwSNMRdF3Hk oXxFxna/cNnjrclNEN5i5KEaLbJPvXmrBGJ66RHpDDA9jmoUwRReHRLR9Iae8Mh04x+t 0wpVBVR9W1hHqVQJlgJO8ImRxgrokrTxmnjUUraDOx2zzQebWgBAX+vT0a8HvAkt6xlV VC2G3xY7aE2L6ExE+tPFQKiRuo3XCeu2KsXolqZgKpTQtCuuuheEoFKXIS8vEuGbgNVW qaUg==
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=Q5KSnTkRxPQF9m8mE9dU1JUZeNwtdvELgrsRPQEAzOc=; b=KOHAQ2/6U6g/4EgtEZVc9p3jm03MbEN817bT9gj3Z8jAL/8Xyj+SC7wDEq5ZYDiZM0 jyOMk4NXc8kw+2EMXmcvBUAwf2fvmguTmHp3mp1Tl7RJDZB/EZnsexb0vCRnlAggzhiF nIY8oIWeqJaROMGGe37fm0MhTfzvskJxsf+RbqslD4vrAH7r9RqkWAXUOWPzSZyFBwi+ bYCzmJzrJoWrPff5HEVBOWxpyXcSlYtBMK4jLhUxbV9K1fD8pi5oxIckoOhukbZapBkL YS4QkC/R898zVOdPFGIEwSxdYqKiPR/Kg8NQAZ52gJ3K6TJ+I7150MPrhqQyD0xEDvjV SHhQ==
X-Gm-Message-State: AIkVDXJKNNvQSnpYP0yqW4hTxX66P2hFOXwD4CFpaWf6+IU2Enjkskoxy1zk9Xe2+1wGvBjX7XMAxSiBzZ4gHQ==
X-Received: by 10.202.44.216 with SMTP id s207mr22746249ois.23.1483358077319; Mon, 02 Jan 2017 03:54:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.137.202 with HTTP; Mon, 2 Jan 2017 03:54:36 -0800 (PST)
In-Reply-To: <YTXPR01MB01893591AC828FB15E2D8C4CDD6C0@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM>
References: <20161213171902.Horde.MkS1YMOM6VpxA0Z7rSMTe7P@mail.telka.sk> <CAABAsM5L0xdKodxk1dRSugLyROzn2JzgDkq6kdHE0LuGcfh++A@mail.gmail.com> <20161213181734.Horde.EqgB09El8rupnkesIQaBwJ3@mail.telka.sk> <CADaq8jcq2C0o8EWXoGjxDn58sV_J+-SP-=rj934Se-DV69b-pw@mail.gmail.com> <20161214112112.Horde.aPh8AjT6iWRl37CULwihyV7@mail.telka.sk> <CAABAsM7v6y0bsb0jKzfvobkUjniTLhM3uv8FYjo07HcLD2004w@mail.gmail.com> <20161227144414.GA32002@fieldses.org> <CADaq8jck14SKL6Ua9QxbqPyX1=1aaA7+76wv-__EWFvh7ZcEJA@mail.gmail.com> <C496AE44-0F27-4B66-A1F6-A76AEAFD7A90@gmail.com> <20161229024703.GA21325@fieldses.org> <20161229074830.GA3002@lst.de> <CADaq8jd__SJHP-4aJPbW9GscKRc6cwSe26VYt3w_GPcpuN3QHQ@mail.gmail.com> <c5251671-2408-eb7e-69ab-7b4eeda35f03@talpey.com> <YTXPR01MB01893591AC828FB15E2D8C4CDD6C0@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM>
From: David Noveck <davenoveck@gmail.com>
Date: Mon, 2 Jan 2017 06:54:36 -0500
Message-ID: <CADaq8jf+THqEy3wYqr9St3Z9BMBBnAGRT7hsbJRvjr9U3TWF=g@mail.gmail.com>
To: Rick Macklem <rmacklem@uoguelph.ca>
Content-Type: multipart/alternative; boundary=001a1147d7d44601f705451b37c8
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/u7KQLsQ7aVj9PTGz5FvWLfLK_tE>
Cc: Tom Talpey <tom@talpey.com>, "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: Mon, 02 Jan 2017 11:54:40 -0000

> Actually replying to a random thread, mostly Dave's...

The big element of randomness/confusion is whether the questions with
regard to delegations are posed with regard to NFSv4.0, in which the client
is doing silly rename, NFSv4.1 in which OPEN4_RESULT_PRESERVE_UNLINKED is
returned, or to a hypothetical extension in which silly
rename is disallowed/deprecated.

As a result, the handling of your scenario is going to have a big dose of
"it depends" but I'll try to clarify as well as I can.

> Is the client expected to acquire Opens against the server and return the
> Delegation? (This seems like more work than just doing good old
sillyrename?)

In the case of v4.0, no.  However, if the client is doing silly rename,
then the RENAME may trigger a delegation recall.  A client could choose to
return the delegation in advance to forstall the need for a recall and
reduce latency.  After all, if you are removing a file, the consequent file
non-existence assures you that no other clients have it open and the
delegation might well be considered superfluous. YMMV.

In the case of OPEN4_RESULT_PRESERVE_UNLINKED, the situation is unclear.
The existing text is not clear as to whether the server's promise to retain
the inode as long as the file is open
applies in the case in which a delegation allows a client-local open to
exist.  If we decide to try to revitalize
OPEN4_RESULT_PRESERVE_UNLINKED (unlikely in my opinion), it needs to be
clear that the potential
existence of local open needs to be taken into account.  However, if this
is done it should be clear that there
is no requirement to promptly resolve the question of the existence of such
local opens.

With regard to a hypothetical replacement for OPEN4_RESULT_PRESERVE_UNLINKED,
the handling
should be the same.

> Or does a Delegation have the same effect as an Open against the file on
the server.

That's the way things should be, if the server is making the decision, but
but we are not there yet.


On Sun, Jan 1, 2017 at 6:19 PM, Rick Macklem <rmacklem@uoguelph.ca> wrote:

> Tom Talpey wrote:
> On 1/1/2017 8:13 AM, David Noveck wrote:
> > Btw, my preferred title for such a document, almost certain to be
> > rejected, is "Silly Rename Must Die" :-)
> Actually replying to a random thread, mostly Dave's...
>
> A case that I wasn't clear on w.r.t. this is:
> - The client holds a delegation for the file.
> - The client issues opens locally w.r.t. this delegation.
> - A process/thread on the client does a "Remove" of the file.
>
> Is the client expected to acquire Opens against the server and return the
> Delegation? (This seems like more work than just doing good old
> sillyrename?)
> - Or does a Delegation have the same effect as an Open against the file on
> the
>   server.
>
> rick
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>