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

Trond Myklebust <trondmy@gmail.com> Mon, 02 January 2017 12:52 UTC

Return-Path: <trondmy@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 276D01294F0 for <nfsv4@ietfa.amsl.com>; Mon, 2 Jan 2017 04:52:56 -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 7APHhlgmLj4M for <nfsv4@ietfa.amsl.com>; Mon, 2 Jan 2017 04:52:54 -0800 (PST)
Received: from mail-lf0-x242.google.com (mail-lf0-x242.google.com [IPv6:2a00:1450:4010:c07::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 7D786128B37 for <nfsv4@ietf.org>; Mon, 2 Jan 2017 04:52:53 -0800 (PST)
Received: by mail-lf0-x242.google.com with SMTP id y21so40031668lfa.0 for <nfsv4@ietf.org>; Mon, 02 Jan 2017 04:52:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=AqNxisWyiZwgcoeR/I1LS4wp21Lx01O3F7qmYoHPvhk=; b=SCjElMLZjf2CmJF6hCp1lFtCwtS2wrPLTMJHUe8nkPmFYV8+OZg7l6Q5QHbMIiJub5 RjdS//LQkZ71+HUYBg7q7KBkYqqMZv1NOT07nrdwHZY1h9qUHdfkstKHgPWCBWHiCnO2 LWUYO0kNukqSJ4Lhxj3ku66mzoQEjhwRS2XBFMcru34qxtRd/sXb0uaKlbUydv/Gukj+ NIb8+HdjPVm09z6kPm6BdGT3ESAx7yFAbKUvY0zEqKfwo7V9yEaarCmvxvCkcgBh52EB 1VOtqLAZC/dAkFhHanLy0Ul+RnFvdQmYHG16Tl0rviMFhvf86Kxtvmkf6wSvxj9kAC0X 2thg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=AqNxisWyiZwgcoeR/I1LS4wp21Lx01O3F7qmYoHPvhk=; b=Micqg7Hhhzyf3jFNwN2np2it17w703AjXdgEar5YtUN5RhmpJWD+KypP9CGUEI9Omv HYEi/+mrd8AWsmkjzvs7dPrILDmFkuABO1V0OBqnBURX2CeWnMNQUKYnVRdsgY5KBYkj sSvehveup+xITZ9HiPxz5MlSvEWio2bij7Jbd2Z89uF4T6B69gjlacjiQyTfLqiWLhz7 IVDwU3nk2bqVddm7GSe/ut+GS29q369aK+jzVXnu/CTCFvylw4rNg4c1DCmzRlYoDHL2 sI7I8R4xoQgQNzVvaQTb1dZgVhoxRvMXNzZRLYHTToPKWDrg6ig4JkwQ/ZpfOqWtjxSX W/fg==
X-Gm-Message-State: AIkVDXLSluZ5lRJ98umsxGnQf/yrojVrNkcfr3fl0W0Ma81GppqdWxrffqNnaG7q/DIy0g==
X-Received: by 10.25.10.6 with SMTP id 6mr15982491lfk.63.1483361571472; Mon, 02 Jan 2017 04:52:51 -0800 (PST)
Received: from [10.0.1.13] (9.42.202.84.customer.cdi.no. [84.202.42.9]) by smtp.gmail.com with ESMTPSA id l138sm8141533lfl.44.2017.01.02.04.52.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Jan 2017 04:52:50 -0800 (PST)
From: Trond Myklebust <trondmy@gmail.com>
Message-Id: <6B1462D8-4688-459C-8794-A64E182ADDC4@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_063CF971-5232-45D7-A14B-8D7DD81D8C9C"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Mon, 2 Jan 2017 13:52:48 +0100
In-Reply-To: <CADaq8jfGCEKWRv8pb3VMZFtLN27dC_EewY=h448VNcBJkGFVQA@mail.gmail.com>
To: Dave Noveck <davenoveck@gmail.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> <CAABAsM5g8Y_vPMC5Kyc9s7zErw-7CydKNf4V_-qbUjjP=_yS5A@mail.gmail.com> <CADaq8jfGCEKWRv8pb3VMZFtLN27dC_EewY=h448VNcBJkGFVQA@mail.gmail.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/_v3znD8KOPD7ZlCblcvVEbxU9aA>
Cc: Tom Talpey <tom@talpey.com>, Rick Macklem <rmacklem@uoguelph.ca>, IETF NFSv4 WG Mailing List <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 12:52:56 -0000

> On Jan 2, 2017, at 13:11, David Noveck <davenoveck@gmail.com> wrote:
> 
> > If you read RFC7530, then the client is expected to return the delegation before doing any form of RENAME or REMOVE
> 
> Could you be more specific about where you saw that?  I tried to find it but didn't succeed.  In fact, with regard to RENAME, the text makes the need for a recall conditional about whether the server in question might disallow RENAMEs depending on what existing opens deny.  I don't remember any statement about expectations regarding delegation return in advance of these ops.

See:
https://tools.ietf.org/html/rfc7530#section-10.4.4 <https://tools.ietf.org/html/rfc7530#section-10.4.4>

10.4.4 <https://tools.ietf.org/html/rfc7530#section-10.4.4>.  Recall of Open Delegation

   The following events necessitate the recall of an open delegation:

   o  Potentially conflicting OPEN request (or READ/WRITE done with
      "special" stateid)

   o  SETATTR issued by another client

   o  REMOVE request for the file

   o  RENAME request for the file as either source or target of the
      RENAME

   Whether a RENAME of a directory in the path leading to the file
   results in the recall of an open delegation depends on the semantics
   of the server file system.  If that file system denies such RENAMEs
   when a file is open, the recall must be performed to determine
   whether the file in question is, in fact, open.

Note that the above special case appears only to apply to _directories_. It is not qualifying the “RENAME request for the file as either source or target…”.

There is also https://tools.ietf.org/html/rfc7530#section-10.4 <https://tools.ietf.org/html/rfc7530#section-10.4>

   When a single client holds an OPEN_DELEGATE_READ delegation, it is
   assured that no other client may modify the contents or attributes of
   the file.  If more than one client holds an OPEN_DELEGATE_READ
   delegation, then the contents and attributes of that file are not
   allowed to change.  When a client has an OPEN_DELEGATE_WRITE
   delegation, it may modify the file data since no other client will be
   accessing the file's data.  The client holding an OPEN_DELEGATE_WRITE
   delegation may only affect file attributes that are intimately
   connected with the file data: size, time_modify, and change.

That last sentence implies (but does not state explicitly) that the client must give up the write delegation if it wants to modify other file attributes.

> 
> > since the server has no stateid or session id with which to identify the origin of the RPC call.
> 
> True statement about an annoying aspect of v4.0, but I'm not clear about where it appears in RFC7530.

It doesn’t, but that was the main argument for recalling the delegation in the cases.

> 
> > It is less obvious that this needs be the case for NFSv4.x (x>0), but I can't remember seeing any changes to those texts in RFC5661.
> 
> Once we find the text in RFC7530, we can address RFC5661.  If the text you recall seeing in RFC7530 appears unchanged in RFC5661, we might need an errata.
> 


https://tools.ietf.org/html/rfc5661#section-10.4.4 <https://tools.ietf.org/html/rfc5661#section-10.4.4>


The text in RFC7530 was a straight cut n’ paste job from RFC5661.

> 
> On Sun, Jan 1, 2017 at 6:36 PM, Trond Myklebust <trondmy@gmail.com <mailto:trondmy@gmail.com>> wrote:
> 
> 
> On 2 January 2017 at 00:19, Rick Macklem <rmacklem@uoguelph.ca <mailto: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.
> 
> If you read RFC7530, then the client is expected to return the delegation before doing any form of RENAME or REMOVE, since the server has no stateid or session id with which to identify the origin of the RPC call.
> 
> It is less obvious that this needs be the case for NFSv4.x (x>0), but I can't remember seeing any changes to those texts in RFC5661.
> 
> Cheers
>   Trond
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org <mailto:nfsv4@ietf.org>
> https://www.ietf.org/mailman/listinfo/nfsv4 <https://www.ietf.org/mailman/listinfo/nfsv4>
> 
>