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

Posted Sep 12, 2021 9:23 UTC (Sun) by walex (guest, #69836)
In reply to: The Btrfs inode-number epic (part 2: solutions) by josefbacik
Parent article: The Btrfs inode-number epic (part 2: solutions)

«This is a problem of interfaces. Btrfs has subvolumes, which are just their own b-tree, and the inode numbers are just a value inside of that tree. Since they are different trees you can share inode numbers across multiple trees. However each tree has their own unique ID.»

This seems a weak defense of the current Btrfs situation, and it is based on a mispresentation of UNIX filesystem semantics, regardless of the details of the API:

In UNIX each filesystem instance has at least one root directory, and each root directory and its descendant i-nodes have a unique "device-id", which was once upon a time the device-id of the containing block device, but need not be (e.g. filesystem instances not contained in any block device).
In UNIX there is no restriction against having multiple filesystem instances in a block device, or having multiple root directories in a filesystem instance (even if both are not traditionally possible).
The only restriction is that (optionally) a filesystem type can deny hard links between a directory and an i-node with different device-ids.

In particular there is no obligation for mounted root directories of filesystem instances to be registered in '/etc/fstab' or anywhere else.

Each Btrfs pr ZFS subvolume or snapshot is just a different root directory in a filesystem instance, so Btrfs (and ZFS, and soon 'bcachefs') respect all these properties, well written NFS servers have no problems with them, and therefore there is simply no issue with them and NFS, and this whole discussion is pointless.