From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1753940AbdBFPSc (ORCPT <rfc822;w@1wt.eu>);
        Mon, 6 Feb 2017 10:18:32 -0500
Received: from bedivere.hansenpartnership.com ([66.63.167.143]:47418 "EHLO
        bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK)
        by vger.kernel.org with ESMTP id S1753710AbdBFPSZ (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 6 Feb 2017 10:18:25 -0500
Message-ID: <1486394296.2474.49.camel@HansenPartnership.com>
Subject: Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: "J. R. Okajima" <hooanon05g@gmail.com>,
        Djalal Harouni <tixxdz@gmail.com>, Chris Mason <clm@fb.com>,
        Josh Triplett <josh@joshtriplett.org>,
        "Eric W. Biederman" <ebiederm@xmission.com>,
        Andy Lutomirski <luto@kernel.org>,
        Seth Forshee <seth.forshee@canonical.com>,
        linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-security-module@vger.kernel.org,
        Dongsu Park <dongsu@endocode.com>,
        David Herrmann <dh.herrmann@googlemail.com>,
        Miklos Szeredi <mszeredi@redhat.com>,
        Alban Crequy <alban.crequy@gmail.com>,
        Al Viro <viro@ZenIV.linux.org.uk>,
        "Serge E. Hallyn" <serge@hallyn.com>, Phil Estes <estesp@gmail.com>
Date: Mon, 06 Feb 2017 07:18:16 -0800
In-Reply-To: <20170206145044.7xlm6l72kystp5zc@thunk.org>
References: <1486235880.2484.17.camel@HansenPartnership.com>
         <1486235972.2484.19.camel@HansenPartnership.com> <4608.1486351540@jrobl>
         <1486363583.2496.63.camel@HansenPartnership.com>
         <20170206145044.7xlm6l72kystp5zc@thunk.org>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.16.5 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, 2017-02-06 at 09:50 -0500, Theodore Ts'o wrote:
> On Sun, Feb 05, 2017 at 10:46:23PM -0800, James Bottomley wrote:
> > Yes, I know the problem.  However, I believe most current linux
> > filesystems no longer guarantee stable, for the lifetime of the 
> > file, inode numbers.  The usual docker container root is overlayfs,
> > which, similarly doesn't support stable inode numbers.  I see the 
> > odd complaint about docker with overlayfs having unstable inode
> > numbers, but none seems to have any serious repercussions.
> 
> Um, no.  Most current linux file systems *do* guarantee stable inode
> numbers.  For one thing, NFS would break horribly if you didn't have
> stable inode numbers.  Never mind applications which depend on POSIX
> semantics.  And you wouldn't be able to save games in rogue or
> nethack, either.  :-)

I believe that's why we have the superblock export operations to
manufacture unique filehandles in the absence of inode number
stability.  The generic one uses inode numbers, but it doesn't have to.
 I thought reiserfs (if we can go back that far) was the first
generally used filesystem that didn't guarantee stable inode numbers,
so we have a lot of historical precedence.

Thanks to reiserfs, I thought we also iterated to weak stability
guarantees for inode numbers which mean no inconsistencies in
applications that use inode numbers for caching?  It's still not POSIX,
but I thought it was good enough for most use cases.

> Overlayfs may not, currently, but it's considered a bug.

James