The Btrfs inode-number epic (part 2: solutions)

Subvolume Y can be a writeable snapshot clone of subvolume X. And you want creating snapshots to be fast, and not use excess disk space. Needing to iterate over every file in X to assign each one a new centrally-assigned-unique inode in Y would be unfortunate both in terms of time and space it would take.

Creating a subvol snapshot instantly duplicates every inode number that already exists in the snapshot source subvol to the target subvol. "Instantly" is a core requirement of the feature set--if a filesystem cannot create a subvol snapshot instantly, there is no performance or consistency advantage over userspace emulation with 'cp -a --reflink=always', and it is better not to implement the subvol feature set at all (which is roughly why XFS doesn't do it).

To get globally unique and stable inode numbers without a separate subvol ID, the filesystem would have to dynamically remap duplicate inode numbers from subvol-local values to globally-unique values every time a readdir() or stat() happened. This adds some overhead to all read operations that filesystem maintainers are reluctant to implement. They would prefer some more efficient way to tell an application "this is a distinct inode number namespace but not a distinct filesystem" so that applications that rely on the uniqueness feature can bear some of the costs (including opportunity costs) of implementing it, while not imposing new costs (such as new O(log(N)) search costs on every stat(), or exploding /proc/mounts and `df` output size) on applications that don't care about inode uniqueness.

The NFS server could maintain its own persistent unique inode numbers in a mapping table outside of the filesystem, and not send the filesystem's inode numbers to clients at all, but that has obvious and onerous runtime costs (the NFS server would have to maintain persistent state proportional to filesystem size).