https://bugs.kde.org/show_bug.cgi?id=402154
--- Comment #34 from Joachim Wagner <jwag...@computing.dcu.ie> --- (In reply to tagwerk19 from comment #33) > statvfs and "stat -f" give a 64 bit "Filesystem ID" and I was imagining you > were talking about that. No, I meant "baloo-internal filesystem ID", a sequentially allocated number as in the proposal discussed before. Difference in my proposal is that a new mount point triggers the allocation, rather than a new UUID+subvolid pair that may be difficult to obtain. > http://lkml.iu.edu/hypermail/linux/kernel/0809.0/0593.html It says "For bfs and xfs it's the block device". This means the ID from stat- f it is NOT suitable as a filesystem ID as the block device major:minor can change. Examples: (1) 2 or more NVMe SSDs: While the first SSD is always /dev/nvme0n1 and the 2nd /dev/nvme1n1, it is random which one gets 259:0. (2) 2 ore more dm-crypt devices with same iter-time: It is random which one becomes /dev/dm-0, which always is 254:0. > It looks straightforward to get the filesystem ID for a file. I haven't seen yet anywhere here a filesystem ID that is stable across restarts and accessible in a standardised way for any filesystem type. Hence my proposal to move away from system-provided IDs and to use the mount point as an identifier instead. -- You are receiving this mail because: You are watching all bug changes.
