Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: [PATCH/RFC 0/4] Attempt to make progress with btrfs dev number
  strangeness.
From:   NeilBrown <neilb@suse.de>
To:     Josef Bacik <josef@toxicpanda.com>, Chris Mason <clm@fb.com>,
        David Sterba <dsterba@suse.com>
Cc:     linux-fsdevel@vger.kernel.org,
        Linux NFS list <linux-nfs@vger.kernel.org>,
        Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Date:   Mon, 09 Aug 2021 13:55:27 +1000
Message-ID: <162848123483.25823.15844774651164477866.stgit@noble.brown>
User-Agent: StGit/0.23
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Precedence: bulk

I continue to search for a way forward for btrfs so that its behaviour
with respect to device numbers and subvols is somewhat coherent.

This series implements some of the ideas in my "A Third perspective"[1],
though with changes is various details.

I introduce two new mount options, which default to
no-change-in-behaviour.

 -o inumbits=  causes inode numbers to be more unique across a whole btrfs
               filesystem, and is many cases completely unique.  Mounting
               with "-i inumbits=56" will resolve the NFS issues that
               started me tilting at this particular windmill.

 -o numdevs=  can reduce the number of distinct devices reported by
              stat(), either to 2 or to 1.
              Both ease problems for sites that exhaust their supply of
              device numbers.
              '2' allows "du -x" to continue to work, but is otherwise
              rather strange.
              '1' breaks the use of "du -x" and similar to examine a
              single subvol which might have subvol descendants, but
              provides generally sane behaviour
              "-o numdevs=1" also forces inumbits to have a useful value.

I introduce a "tree id" which can be discovered using statx().  Two
files with the same dev and ino might still be different if the tree-ids
are different.  Connected files with the same tree-id may be usefully
considered to be related.

I also change various /proc files (only when numdevs=1 is used) to
provide extra information so they are useful with btrfs despite subvols.
/proc/maps /proc/smaps /proc/locks /proc/X/fdinfo/Y are affected.
The inode number becomes "XX:YY" where XX is the subvol number (tree id)
and YY is the inode number.

An alternate might be to report a number which might use up to 128 bits.
Which is less likely to seriously break code?

Note that code which ignores badly formatted lines is safe, because it
will never currently find a match for a btrfs file in these files
anyway.  The device number they report is never returned in st_dev for
stat() on any file.

The audit subsystem and one or two other places report dev/ino and so
need enhanced, but I haven't tried to address those.

Various trace points also report dev/ino.  I haven't tried thinking
about those either.

Thanks for your upcoming replies!

NeilBrown

---

NeilBrown (4):
      btrfs: include subvol identifier in inode number if -o inumbits=...
      btrfs: add numdevs= mount option.
      VFS/btrfs: add STATX_TREE_ID
      Add "tree" number to "inode" number in various /proc files.


 fs/btrfs/ctree.h          | 17 +++++++++++++++--
 fs/btrfs/disk-io.c        | 24 +++++++++++++++++++++---
 fs/btrfs/inode.c          | 39 ++++++++++++++++++++++++++++++++++++++-
 fs/btrfs/ioctl.c          |  6 ++++--
 fs/btrfs/super.c          | 31 +++++++++++++++++++++++++++++++
 fs/inode.c                |  1 +
 fs/locks.c                | 12 +++++++++---
 fs/notify/fdinfo.c        | 19 ++++++++++++++-----
 fs/proc/nommu.c           | 11 ++++++++---
 fs/proc/task_mmu.c        | 17 ++++++++++++-----
 fs/proc/task_nommu.c      | 11 ++++++++---
 fs/stat.c                 |  2 ++
 include/linux/fs.h        |  3 ++-
 include/linux/stat.h      | 13 +++++++++++++
 include/uapi/linux/stat.h |  3 ++-
 samples/vfs/test-statx.c  |  4 +++-
 16 files changed, 183 insertions(+), 30 deletions(-)

--
Signature