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 S1753060AbdBFDZq (ORCPT <rfc822;w@1wt.eu>);
        Sun, 5 Feb 2017 22:25:46 -0500
Received: from mail05-md.ns.itscom.net ([175.177.155.115]:44378 "EHLO
        mail05-md.ns.itscom.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752732AbdBFDZo (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Sun, 5 Feb 2017 22:25:44 -0500
From: "J. R. Okajima" <hooanon05g@gmail.com>
Subject: Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Djalal Harouni <tixxdz@gmail.com>, Chris Mason <clm@fb.com>,
        Theodore Tso <tytso@mit.edu>, 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>
In-Reply-To: <1486235972.2484.19.camel@HansenPartnership.com>
References: <1486235880.2484.17.camel@HansenPartnership.com> <1486235972.2484.19.camel@HansenPartnership.com>
Date: Mon, 06 Feb 2017 12:25:40 +0900
Message-ID: <4608.1486351540@jrobl>
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

James Bottomley:
> This allows any subtree to be uid/gid shifted and bound elsewhere.  It
	:::

Interesting.
But I am afraid that the inconsistency problem of the inode numbers will
happen.

shiftfs_new_inode() uses get_next_ino() which means
- 1st time: inodeA is created and cached, inumA is assigned
- after using inodeA, it will be discarded from the cache
- 2nd time: inodeA is looked-up again, and another inode number (inumB)
  is assgined.

This inconsistency will not be a problem for the "pure virtual" fs such
as procfs and sysfs. But your shiftfs is not pure as them. Shiftfs will
be used as a wrapper (or "binder" which means bind-mount) of an orginary
filesystem.
The symptom of this problem from users perspective will be
- find -inum doesn't work
- git-status doesn't work, which keeps st_dev and st_ino and compares
  the current files.
Of course they will be limited to when the target dir is huge and/or
system memory is low. As long as the inode cache is large enough to hold
all necessary inodes, the problem won't happen.

If shiftfs will supports exporting via NFS in the future, the
consistency of inum will be important too.


J. R. Okajima