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

Christoph Hellwig <hch@lst.de> Sun, 01 January 2017 13:48 UTC

Return-Path: <hch@lst.de>
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 2E2D412945D for <nfsv4@ietfa.amsl.com>; Sun, 1 Jan 2017 05:48:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5
X-Spam-Level:
X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.1] 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 Am8XNIVn283M for <nfsv4@ietfa.amsl.com>; Sun, 1 Jan 2017 05:48:48 -0800 (PST)
Received: from newverein.lst.de (verein.lst.de [213.95.11.211]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CD1B12940F for <nfsv4@ietf.org>; Sun, 1 Jan 2017 05:48:48 -0800 (PST)
Received: by newverein.lst.de (Postfix, from userid 2407) id 94155DE53C; Sun, 1 Jan 2017 14:48:46 +0100 (CET)
Date: Sun, 1 Jan 2017 14:48:46 +0100
From: Christoph Hellwig <hch@lst.de>
To: David Noveck <davenoveck@gmail.com>
Message-ID: <20170101134846.GA18240@lst.de>
References: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CADaq8jd__SJHP-4aJPbW9GscKRc6cwSe26VYt3w_GPcpuN3QHQ@mail.gmail.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/92yRGcuelAEGIi_dnx6_FHUiAHQ>
Cc: Bruce James Fields <bfields@fieldses.org>, Christoph Hellwig <hch@lst.de>, 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: Sun, 01 Jan 2017 13:48:50 -0000

On Sun, Jan 01, 2017 at 08:13:55AM -0500, David Noveck wrote:
> You need to delay the deletion until after the grace period is over.  There
> may be technical issues with this but the biggest hurdle may may be
> architectural/political.  I expect that people involved in file system
> recovery may have trouble with the idea that the NFS server is telling them
> when they can and cannot do various pieces of file system recovery.

Wearing my local fs hat the only issue I have is that I'd like to avoid
the case where people accidentally configure their fs to never reclaim
the unlinked but open inodes after a crash.

> It might be more possible to ask them to complete recovery but move the
> unlinked inodes to a directory like /unlinked-inodes and consider the
> recovery complete before NFS actually runs.  If that is OK, and I believe
> it is, the result would be almost the same as the NFS server moving the
> file to that directory in the first place, using a server-based silly
> rename.

For the classis text book case of file systems with intent log this
doesn't make sense.  Open but unlinked inodes are only tracked in the
unlinked inode list, but do not have a name attached to them any more.
So we'd have to do a lot of effort to move it into a directory using
synthetic names while we already have a better data structure built
for exactly this use case.  We'll just need to delay the action performed
on it a little bit.  And that actions is really trivial - basically the
inodes is read into memory and then released again to execute the same
code we'd execute after dropping the last reference to an open but
unlinked inode.

> > It's a major pain for getting sensible semantics out of NFS.
> 
> Please elaborate.  Would a server-based silly rename allow the sensible
> semantics you are looking for?

After delving so much into internals above I'll switch to my protocol
developers hereand say: we should only specify the on the wire semantics,
how it's implemented on the server is not our business.

A NFS server that moves all files that are unlinked but open by a client
(note that this might be a problem for local opens or unlinks not going
through the nfs server) could provide semantics very close to the real
thing, but it would have to be creative about adjusting the link counts
sent to the client.

With my experience in local file systems and nfs servers I'd say it's much
simpler to let the file system do the hard work and let the NFS server
delay reclaiming of unlinked inodes after a crash in some way.