On Sun, 15 Aug 2021 09:39:08 +0200
Goffredo Baroncelli [off-list ref] wrote:

I am sure that it was discussed already but I was unable to find any track
of this discussion. But if the problem is the collision between the inode
number of different subvolume in the nfd export, is it simpler if the export
is truncated to the subvolume boundary ? It would be more coherent with the
current behavior of vfs+nfsd.

See this bugreport thread which started it all:
https://www.spinics.net/lists/linux-btrfs/msg111172.html

In there the reporting user replied that it is strongly not feasible for them
to export each individual snapshot.

In fact in btrfs a subvolume is a complete filesystem, with an "own
synthetic" device. We could like or not this solution, but this solution is
the more aligned to the unix standard, where for each filesystem there is a
pair (device, inode-set). NFS (by default) avoids to cross the boundary
between the filesystems. So why in BTRFS this should be different ?

From the user point of view subvolumes are basically directories; that they
are "complete filesystems"* is merely a low-level implementation detail.

* well except they are not, as you cannot 'dd' a subvolume to another
blockdevice.

Why don't rename "ino_uniquifier" as "ino_and_subvolume" and leave to the
filesystem the work to combine the inode and the subvolume-id ?

I am worried that the logic is split between the filesystem, which
synthesizes the ino_uniquifier, and to NFS which combine to the inode. I am
thinking that this combination is filesystem specific; for BTRFS is a simple
xor but for other filesystem may be a more complex operation, so leaving an
half in the filesystem and another half to the NFS seems to not optimal if
other filesystem needs to use ino_uniquifier.

I wondered a bit myself, what are the downsides of just doing the
uniquefication inside Btrfs, not leaving that to NFSD?

I mean not even adding the extra stat field, just return the inode itself with
that already applied. Surely cannot be any worse collision-wise, than
different subvolumes straight up having the same inode numbers as right now?

Or is it a performance concern, always doing more work, for something which
only NFSD has needed so far.

-- 
With respect,
Roman