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

bfields@fieldses.org (J. Bruce Fields) Tue, 27 December 2016 14:44 UTC

Return-Path: <bfields@fieldses.org>
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 CD7D7129A83 for <nfsv4@ietfa.amsl.com>; Tue, 27 Dec 2016 06:44:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.002
X-Spam-Level:
X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 2k8wRjF1bCcY for <nfsv4@ietfa.amsl.com>; Tue, 27 Dec 2016 06:44:21 -0800 (PST)
Received: from fieldses.org (fieldses.org [173.255.197.46]) by ietfa.amsl.com (Postfix) with ESMTP id 83DF9129A7E for <nfsv4@ietf.org>; Tue, 27 Dec 2016 06:44:15 -0800 (PST)
Received: by fieldses.org (Postfix, from userid 2815) id D04C13F4; Tue, 27 Dec 2016 09:44:14 -0500 (EST)
Date: Tue, 27 Dec 2016 09:44:14 -0500
To: Trond Myklebust <trondmy@gmail.com>
Message-ID: <20161227144414.GA32002@fieldses.org>
References: <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> <CAABAsM7v6y0bsb0jKzfvobkUjniTLhM3uv8FYjo07HcLD2004w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAABAsM7v6y0bsb0jKzfvobkUjniTLhM3uv8FYjo07HcLD2004w@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
From: bfields@fieldses.org (J. Bruce Fields)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/f21Ct03dl9nS-XBdOggXeizrnFw>
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, 27 Dec 2016 14:44:23 -0000

On Wed, Dec 14, 2016 at 09:28:41AM -0500, Trond Myklebust wrote:
> 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?

I think this is what OPEN4_RESULT_PRESERVE_UNLINKED in 5661 was meant to
do.  It'd be interesting to try an implementation and see if your other
points are addressed, but I haven't thought about it in a long time.

--b.

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

> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4