Feature request: mount option to specify the device number reported as stat.st_dev

[jowagner]

Current Situation

A filesystem's device number such as reported by stat() as stat.st_dev (or after Device: in the output of stat) can either be

1. derived from major and minor of the underlying block device, e.g. xfs, or be
2. allocated at mount time, e.g. btrfs.

Even in the former case, the device number can change between restarts, e.g. when multiple dm-crypt devices are created in different order. Changing device numbers cause trouble for applications that use the device number to identify a filesystem across restarts, e.g. KDE's baloo file indexer.

Feature Request

A mount option to specify the device number would fix this trouble without requiring applications to move to alternative ways of identifying filesystems, e.g. based on UUID and sub-volume ID. This option could be general, i.e. the device number can be set for any filesystem, including those that normally derive it from major and minor of their block device(s).

If code for choosing the device number is currently in each filesystem module this feature may involve providing and promoting a new interface for choosing the filesystem's device number that

• addresses the common cases such as multiple backing devices and subvolumes
• gives users control of the device number in a standardised way
• prevents use of the same device number for multiple mounted filesystems

Considerations

The implementation would probably be simplified if the specified device number must come from a reserved pool. Otherwise, care must be taken that the number does not collide with automatically assigned device numbers, including those allocated later. This means, for example, that an xfs filesystem mounted later cannot use its default (major<<8)+minor of the source device when already in use by another filesystem.

Clarification

This feature is not about the source device but the "device number" reported by the filesystem in stat(). For xfs and probably many other filesystems, this happens to be (major<<8)+minor of the source device but btrfs, for example, allocates a new number for each subvolume.

References

https://bugs.kde.org/show_bug.cgi?id=402154
https://bugs.kde.org/show_bug.cgi?id=404057
https://bugs.kde.org/show_bug.cgi?id=413694
https://unix.stackexchange.com/questions/345220/btrfs-how-to-get-real-device-id
https://stackoverflow.com/questions/4309882/device-number-in-stat-command-output/4309947

Coming from:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=53212 (closed, not coreutils)

[karelzak]

This is something we cannot implement in userspace, such a feature has to be implemented by the Linux kernel.

Please, ask kernel developers for the feature. (Frankly, I have doubts you will be successful:-)

[brauner]

Please, ask kernel developers for the feature. (Frankly, I have doubts you will be successful:-)

Yeah, that won't fly and actually has been proposed in various ways over the years.

[jowagner]

Would you think that chances are somewhat better now given that the issue is no longer restricted to btrfs and dm-crypt users but also extends to having 2 or more NVMe SSDs? Guess what happens to the minor device numbers for the 2nd SSD and its partitions when a partition is added or removed from the first SSD in the example below.

$ ls -l /dev/nvme?n1*
brw-rw---- 1 root disk 259,  0 Jan 21 09:31 /dev/nvme0n1
brw-rw---- 1 root disk 259,  1 Jan 21 09:31 /dev/nvme0n1p1
brw-rw---- 1 root disk 259,  2 Jan 21 09:31 /dev/nvme0n1p2
brw-rw---- 1 root disk 259,  3 Jan 21 09:31 /dev/nvme0n1p3
brw-rw---- 1 root disk 259,  4 Jan 21 09:31 /dev/nvme0n1p4
brw-rw---- 1 root disk 259,  5 Jan 21 09:31 /dev/nvme0n1p5
brw-rw---- 1 root disk 259,  6 Jan 21 09:31 /dev/nvme0n1p6
brw-rw---- 1 root disk 259,  7 Jan 21 09:31 /dev/nvme0n1p7
brw-rw---- 1 root disk 259,  8 Jan 21 09:31 /dev/nvme0n1p8
brw-rw---- 1 root disk 259,  9 Jan 21 09:31 /dev/nvme1n1
brw-rw---- 1 root disk 259, 10 Jan 21 09:31 /dev/nvme1n1p1
brw-rw---- 1 root disk 259, 11 Jan 21 09:31 /dev/nvme1n1p2
[...]