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

Trond Myklebust <trondmy@gmail.com> Wed, 14 December 2016 14:28 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 9BF9A129874 for <nfsv4@ietfa.amsl.com>; Wed, 14 Dec 2016 06:28: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 FBZTk0zlN50t for <nfsv4@ietfa.amsl.com>; Wed, 14 Dec 2016 06:28:42 -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 A21941296E3 for <nfsv4@ietf.org>; Wed, 14 Dec 2016 06:28:42 -0800 (PST)
Received: by mail-oi0-x242.google.com with SMTP id u15so2731372oie.3 for <nfsv4@ietf.org>; Wed, 14 Dec 2016 06:28: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=p74I7soHepV82DueRNTT/jyXJNqB6zVWL3cdE4ZspTY=; b=hBblTC6t1Q4BnCMx4ZWH6oGTYsE3iRUjqXOFFgRIkQYfLWpZ8IUgRBBCCTKbGrA2iK g1YwZvykuXIrddOE45BFZwn2iXmhMlTLyn3khG61cXlYLTOCusE4RxCT3cubiv76fEwg VYMoaCRzuoVM8fAdYkfzlBjcjnHAd+iL4oijNyUnrMmOvLCFoE2KOiWK6gQnr73foJzf OEfeVqVqAEO4+PDt7fx1RJ+JrRUbEliKCcIO7+qeCetollWtNYJ/9BLhHXhRTzLSgoex hfE+lYuWNSG/JQNPTUk+ibahqWejUmVRubaUv/4+IgZxQYpaCF0jUXTMwbwSKPCeuJ0B oWGw==
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=p74I7soHepV82DueRNTT/jyXJNqB6zVWL3cdE4ZspTY=; b=TiL6H2yO+MsW8n5EobXij1vxwC7WagCa98nRHZwUfPWp0qGxdYR42K62DcjdVCyUiC wA+SiYJ/8dyYTJVsUg0ag8TgfG4GlV4CafL77eQB/g2wsOv8b2g7ulAnJA+JVdhKj0C3 nh1c+NLAaEKwBHxdoDlWQNRmUCNVYBMu9hgj0MX/y8ry4i0ruANjqVb9CMRPz1t5eUXQ hUAss9XRnWhxOantlT3020GkIZBod+tfhrs0LazQmBOLZdEH45n/tPfABzzhhKndhevx rS60VCcZnN0ypVQ2M+FcSylLSTwilPEJ7Q3BIqpGxVTDibqVdLZrnRaFpv7hRYBX+ZJh a+ww==
X-Gm-Message-State: AKaTC03viYDmBn3B3xYvkX81pcRsxbQe69NjQNzKyhqexXO4+01zWvzuh8kpRYzYvrzVrIcNz6x1hDfcjWOnpw==
X-Received: by 10.202.0.210 with SMTP id 201mr56833849oia.84.1481725722020; Wed, 14 Dec 2016 06:28:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.17.115 with HTTP; Wed, 14 Dec 2016 06:28:41 -0800 (PST)
In-Reply-To: <20161214112112.Horde.aPh8AjT6iWRl37CULwihyV7@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> <CADaq8jcq2C0o8EWXoGjxDn58sV_J+-SP-=rj934Se-DV69b-pw@mail.gmail.com> <20161214112112.Horde.aPh8AjT6iWRl37CULwihyV7@mail.telka.sk>
From: Trond Myklebust <trondmy@gmail.com>
Date: Wed, 14 Dec 2016 09:28:41 -0500
Message-ID: <CAABAsM7v6y0bsb0jKzfvobkUjniTLhM3uv8FYjo07HcLD2004w@mail.gmail.com>
To: Marcel Telka <marcel@telka.sk>
Content-Type: multipart/alternative; boundary=001a1137984650d15105439f279a
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/zhhPh_Hwg0BMXyFkbWqSDM-GQnU>
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 14:28:44 -0000

On Wed, Dec 14, 2016 at 6:21 AM, Marcel Telka <marcel@telka.sk> wrote:

> Citát David Noveck <davenoveck@gmail.com>om>:
>
>> 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.
>>
>
> Yes, this is exactly what I want to see.
>
>
There are 4 main problems that are inadequately discussed in any of the
existing RFCs, and that you need to address before we can consider
replacing sillyrename (which is well established today, and well understood
by most users).

1) How does the client identify that the server supports this functionality?
2) What functionality is needed on the underlying filesystems on the server?
3) How does the server function in the case of a reboot? What can the
client expect in terms of recoverability?
4) How does the client in practice perform recovery?
   a) In the case of server reboots.
   b) In the case of lease timeouts/network partitions

Note that the lack of open-by-filehandle in NFSv4.0 makes 4.b) more
difficult than it should otherwise be.