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

David Noveck <davenoveck@gmail.com> Mon, 02 January 2017 12:11 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 2F0CE1295C6 for <nfsv4@ietfa.amsl.com>; Mon, 2 Jan 2017 04:11:29 -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 blBHucuhvOke for <nfsv4@ietfa.amsl.com>; Mon, 2 Jan 2017 04:11:27 -0800 (PST)
Received: from mail-oi0-x241.google.com (mail-oi0-x241.google.com [IPv6:2607:f8b0:4003:c06::241]) (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 7F0D3129420 for <nfsv4@ietf.org>; Mon, 2 Jan 2017 04:11:27 -0800 (PST)
Received: by mail-oi0-x241.google.com with SMTP id f201so66254973oib.0 for <nfsv4@ietf.org>; Mon, 02 Jan 2017 04:11:27 -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=w9+HBqR6h4PzyutcVp/qXN8/sjnG9a5rXy+iGr3V8Ao=; b=MGpxn13sGBtto+u3QIiuLaAh0S2CcKshbmMYVnxl4YaUqVRlf75IX7uuZ3IMYLil3a YkP9RZrISLgpzWHm74mUKC1QsuGfxGjhnYALD/AGGnGmG3AaDYaRaPyt5v8OV4ehtZqj X0HmdAq8lUOBB2aJ97cXMzM2TWoVON1rdZNSvLO1BORwOgZnaQy4rH5pMq6mzIDIOdnt ls5I/Zg46JBpie2tvNyWjmcRDSlRSVAM0dXM6FSG9rvvw5r6jeE+EwtHSmpqbum2xhzS 5Xonk47jWYJn6eOB5urooNGM4ww+JqBcNZjha7e7HC7ISaSYWQRySD8ByuSHnbXPdgJ/ AOrQ==
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=w9+HBqR6h4PzyutcVp/qXN8/sjnG9a5rXy+iGr3V8Ao=; b=FGP7bp4jNMznVNR8hM6zFlofA1B03pDNt7kF0L2Ogh4LFWd28Un1Kv8Bv3//vtVGPs ursy1k7rvpt0BYVsBm0OVManJ/tAp3O4JxlWAMQGdfC1ioB+ATsWzoeEyqlyBV5v37wB K1A2Nq9XuPNapcb2sBGKXnXv2d/5bx16O8pfTLFwNf3fiAgQeGP+iJqtWxyj8rLJs2Xa pfN4oou9Rf41kimRrBI14ekS4dvMqZztx0280GXfPQn4r7BKhWfcCT5LlOljnZ384IxC wbIg2Zc7D+poZOIqzf0CyBbUcjFVg3Y5rBHRKa86T1TngxtyOtRZn7Rkc7sg7KcmFDDa 1hVA==
X-Gm-Message-State: AIkVDXK93i2orPjNhfxruO8YmhwtJrpbgYG8ihfqdjTdVf63slASxv/FUuzJ8Z7EtQI116rg1cgXl3Kr5pzcPg==
X-Received: by 10.202.228.83 with SMTP id b80mr28625098oih.214.1483359086921; Mon, 02 Jan 2017 04:11:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.137.202 with HTTP; Mon, 2 Jan 2017 04:11:25 -0800 (PST)
In-Reply-To: <CAABAsM5g8Y_vPMC5Kyc9s7zErw-7CydKNf4V_-qbUjjP=_yS5A@mail.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>
From: David Noveck <davenoveck@gmail.com>
Date: Mon, 2 Jan 2017 07:11:25 -0500
Message-ID: <CADaq8jfGCEKWRv8pb3VMZFtLN27dC_EewY=h448VNcBJkGFVQA@mail.gmail.com>
To: Trond Myklebust <trondmy@gmail.com>
Content-Type: multipart/alternative; boundary=001a1141baaa734e3205451b73f8
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/4f4CY6FZwPzTASAzN1BrEAGeaIk>
Cc: Tom Talpey <tom@talpey.com>, Rick Macklem <rmacklem@uoguelph.ca>, "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 12:11:29 -0000

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

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


On Sun, Jan 1, 2017 at 6:36 PM, Trond Myklebust <trondmy@gmail.com> wrote:

>
>
> On 2 January 2017 at 00:19, 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.
>>
>
> 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
> https://www.ietf.org/mailman/listinfo/nfsv4
>
>