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

Bruce James Fields <bfields@fieldses.org> Thu, 29 December 2016 02:47 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 4C78A129793 for <nfsv4@ietfa.amsl.com>; Wed, 28 Dec 2016 18:47:05 -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 7vZeq3gtAoMU for <nfsv4@ietfa.amsl.com>; Wed, 28 Dec 2016 18:47:04 -0800 (PST)
Received: from fieldses.org (fieldses.org [173.255.197.46]) by ietfa.amsl.com (Postfix) with ESMTP id 70C0E12953B for <nfsv4@ietf.org>; Wed, 28 Dec 2016 18:47:04 -0800 (PST)
Received: by fieldses.org (Postfix, from userid 2815) id F0A543F4; Wed, 28 Dec 2016 21:47:03 -0500 (EST)
Date: Wed, 28 Dec 2016 21:47:03 -0500
From: Bruce James Fields <bfields@fieldses.org>
To: Trond Myklebust <trondmy@gmail.com>
Message-ID: <20161229024703.GA21325@fieldses.org>
References: <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> <CADaq8jck14SKL6Ua9QxbqPyX1=1aaA7+76wv-__EWFvh7ZcEJA@mail.gmail.com> <C496AE44-0F27-4B66-A1F6-A76AEAFD7A90@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <C496AE44-0F27-4B66-A1F6-A76AEAFD7A90@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/VKb8VXOYP3LDdUGqEHOHZAS5UM8>
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 02:47:05 -0000

On Tue, Dec 27, 2016 at 09:24:36PM +0100, Trond Myklebust wrote:
> Sure, but in order to be reboot safe, you need to go well beyond the
> functionality that you describe. As far as I can tell, you need to
> defer the garbage collection that would normally occur when the server
> comes back up again until after the state reclaim has occurred (as you
> describe below).

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.

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:

	- you'll never be able to completely hide that directory.  But
	  maybe we could get some sort of filesystem support for a
	  hidden directory.
	- what if the remove is from a non-nfs user?  Maybe we could get
	  some kind of notification on unlink of an open file, maybe we
	  just live with continuing not to handle this particular case.
	- I guess we need to tell nfs users that the inode's link count
	  is zero?  (Any local users will still see it as one, though?)

--b.