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

Christoph Hellwig <hch@lst.de> Thu, 29 December 2016 07: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 996541299BE for <nfsv4@ietfa.amsl.com>; Wed, 28 Dec 2016 23:48:34 -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 0rD04c_74YBN for <nfsv4@ietfa.amsl.com>; Wed, 28 Dec 2016 23:48:33 -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 E812E1299BC for <nfsv4@ietf.org>; Wed, 28 Dec 2016 23:48:32 -0800 (PST)
Received: by newverein.lst.de (Postfix, from userid 2407) id 735B068C6F; Thu, 29 Dec 2016 08:48:30 +0100 (CET)
Date: Thu, 29 Dec 2016 08:48:30 +0100
From: Christoph Hellwig <hch@lst.de>
To: Bruce James Fields <bfields@fieldses.org>
Message-ID: <20161229074830.GA3002@lst.de>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161229024703.GA21325@fieldses.org>
User-Agent: Mutt/1.5.17 (2007-11-01)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/DR7BQnCS8omS6r9b7u-Js-1SH2s>
Cc: 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: Thu, 29 Dec 2016 07:48:34 -0000

On Wed, Dec 28, 2016 at 09:47:03PM -0500, Bruce James Fields wrote:
> I never seriously worked on it, but for a while I was in the habit of
> running it by people.  Christoph Hellwig thought it was doable (I think
> he suggested some sort of callback from the filesystem during the
> garbage collection, possibly because he had in mind some other
> application for that--but my memory may be wrong).  Chris Mason didn't
> like the idea at all.  He asked what we expect to happen on fsck, or if
> the filesystem gets mounted without nfs getting started, or... some
> other scenarios I forget.

The way open but unlinked files are handled by modern transaction
file systems is that the file system has a list of those inodes
(in XFS this is the unlinked inode list in the allocation group header,
other file systems use different terminologies and slightly different
technics, e.g. in ext4 the list is global for the whole file system).

After an unclean shutdown when file system recovery is run we'll perform
the deferred delete for all the inodes on the unlinked inode list.
At that point the file system could in theory inform NFSD about that
fact.  But at least as far as the current Linux kernel is concerned (
sorry for delving into implementation details, but I guess this is still
easier to understand than an abstract discussion) at the point where
file system performs recovery NFSD has not been started, or at least doesn't
know about the file system yet.   We could still persist that information
somewhere, or use a flag to delay the deletion of unlinked inodes until
NFSD runs.

> We could do the same silly rename tricks on the server side.  Something
> like: create a directory with an unlikely name in the root of the
> export, rename files there on REMOVE.  Possible problems:

Personally I'd love to see sillyrename die.  It's a major pain for
getting sensible semantics out of NFS.

> 	- you'll never be able to completely hide that directory.  But
> 	  maybe we could get some sort of filesystem support for a
> 	  hidden directory.


The unlinked inode list is almost a directory, except that it doesn't
have names for the entries, you can only find inodes on it by the inode
number and generation (aka NFS file handle).