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

David Noveck <davenoveck@gmail.com> Tue, 27 December 2016 18:13 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 9A92112968F for <nfsv4@ietfa.amsl.com>; Tue, 27 Dec 2016 10:13:48 -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 1lihZyZNURZk for <nfsv4@ietfa.amsl.com>; Tue, 27 Dec 2016 10:13:46 -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 F216C1293F4 for <nfsv4@ietf.org>; Tue, 27 Dec 2016 10:13:45 -0800 (PST)
Received: by mail-oi0-x241.google.com with SMTP id v84so48504134oie.2 for <nfsv4@ietf.org>; Tue, 27 Dec 2016 10:13:45 -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=YmlLy+o0InFf2l/a9FSHqEiiHBITdm4yE95k+sG197k=; b=GNgm1iH4+PtCn0cCpfkfaPiA5wvXgfUKnw/qSl/dvM8hJgdl6C9atvtdN94R1HK0ua 9a/GRQws3CcUp1YyMtXstQIoa9clZJTbQmIioJTEQIUNBeA21eIWv5PJJgc0y7CWFhkN vyunYI+NjmrIvodfoy0ltku3+2aSKODy9mAYey9AYQYhRf85Ge6yevzFXaVzDlBHx8rW mUgT8ic64+EWe7rpD+cXZKAECrAtbDS4EtrCPMXS2ey80TyJ8gTMNhGNdYtRZahwiVW6 vPVfN3oF6nIh0Pmj+9+oSRVH41QwMi8wHnTZhhUnKcH6BfvJbIVAMnaMLsmLNZrfbOa6 NCrw==
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=YmlLy+o0InFf2l/a9FSHqEiiHBITdm4yE95k+sG197k=; b=hDVlV6bqX4pIDXtvsWh1HfsxuLsvRNF64deLYJESyiHfDntf/Fib79W7rNM4Vm/poJ 9M8b4AF6br0ui9iBn5eXqji4m3eAsrPH6rcOl5GtBjsnS23cfd1RoxKE9reIIviTRjDC xa0FksOaA25p1YDNaCeW3x7m4DxAcQa/QOLqi75lHtzeDAuy3QftTNySQb7p7HAnw7Y3 N8nY1jMR8ZeQOCG4R7X9txlsSgQCDDBxYyi3tvEPH4Aa7ZuRgPYvJohtGe+3VxEBKSWd c/Y/Kn90MiIBHtKZnNx1GDqUdaSBW+co9oEq9dDTTpFykdH8r7BskyrHpkClKUKYewOP Y+xA==
X-Gm-Message-State: AIkVDXLdZKIcDtZwwO4nfL8iqpNMVMK4OmrJr9vaagFrjxOTPHs70TEfvPi8EN9XX3gHF72fcG/NTsx1V5Q1jQ==
X-Received: by 10.157.24.109 with SMTP id t42mr17537775ott.166.1482862425301; Tue, 27 Dec 2016 10:13:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.137.202 with HTTP; Tue, 27 Dec 2016 10:13:44 -0800 (PST)
In-Reply-To: <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> <20161227144414.GA32002@fieldses.org>
From: David Noveck <davenoveck@gmail.com>
Date: Tue, 27 Dec 2016 13:13:44 -0500
Message-ID: <CADaq8jck14SKL6Ua9QxbqPyX1=1aaA7+76wv-__EWFvh7ZcEJA@mail.gmail.com>
To: "J. Bruce Fields" <bfields@fieldses.org>, Trond Myklebust <trondmy@gmail.com>, Marcel Telka <marcel@telka.sk>
Content-Type: multipart/alternative; boundary=001a1142ebfe1c6aa80544a7d054
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/GPE92BvLlVMb9PEjJ9HQP_n5-3A>
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 18:13:48 -0000

Bruce wrote:

> I think this is what OPEN4_RESULT_PRESERVE_UNLINKED in 5661 was meant to
> do.

In fact it was.  See the sixth bullet in section 1.8 of RFC5661.

The problem I see is that it doesn't solve the problem that Marcel has
pointed out.  If client A
opens the file and client B removes it, there is no way it can decide
whether or not to do a
silly rename.  Since he hasn't opened, the file he doesn't see the flag
indicating it is not
needed.  Also, since the file is not open he has no indication that it is
needed either.  So client
B will do a REMOVE in all cases.

Server implementations may or may not preserve the file until last close.
For those that do,
everything will work out OK, while for those that don't, there isn't much
that the client can
do.  If he did find out the server did not have the support, he has o way
to defer the remove
until last close because he has no way of finding out when this happens,

Trond wrote:

> 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

It appears it has already been considered and spec'd but the spec may not be
adequate.  Sigh!

> (which is well established today, and well understood by most users).

Most people understand why it works when it does but don't understand why
it doesn't
work in some cases.  So they are happy until they aren't.

> 1) How does the client identify that the server supports this
functionality?

The problem is that the client who doesn't open file, the troublesome case,
is exactly the one in which
he receives no information.  The client who does the open finds out silly
rename is not needed, but, in
this case, silly rename seems to work OK.

> 2) What functionality is needed on the underlying filesystems on the
server?

Almost all filesystems have the ability to defer deletion until the last
close.  If they don't, they
are not very usable.  Servers which don't support this are not suffering
from a lack of filesystem
functionality.  Instead, the problem seems to be that some servers have an
NFSv4 open which
either doesn't connect the to the underlying open functionality or there is
no underlying open functionality.

> 3) How does the server function in the case of a reboot? What can the
client expect in terms of recoverability?

This is addressed b section 18.16.3 of rfc5661.  The third bullet on page
 449 says:

Furthermore, the server promises to preserve the file through the
grace period after server restart, thereby giving the client the
opportunity to reclaim its open.


> 4) How does the client in practice perform recovery?
>   a) In the case of server reboots.

I think he just recovers this opens within the grace period.

>   b) In the case of lease timeouts/network partitions

This case is not addressed RFC5661, so far as I can see.  The typical
handling, in which
the locks are all dropped would cause the file to go away.  Courtesy locks
could address the
problem, but the spec doesn't that have to be implemented.

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

True. In v4.1, a client can try an open-by-filehandle and take advantage of
any courtesy locks that the server
has retained.

On Tue, Dec 27, 2016 at 9:44 AM, J. Bruce Fields <bfields@fieldses.org>
wrote:

> 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
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>