On Tue, Jul 30, 2024 at 12:31:57PM +1000, Dave Chinner wrote: > There are at least two different "is this inode identical" > use cases that {st_dev,st_ino} is being used for. > > The first, as Florian described, is to determine if two open fds > refer to the same inode for collision avoidance. > > This works on traditional filesystems like ext4 and XFS, but isn't > reliable on filesystems with integrated snapshot/subvolume > functionality. It's not about snapshot, it's about file systems being broken. Even btrfs for example always has a unique st_dev,st_ino pair, it can just unexpectly change at any subvolume root and not just at a mount point. > That is our long term challenge: replacing the use of {dev,ino} for > data uniqueness disambiguation. Making the identification of owners > of non-unique/shared data simple for applications to use and fast > for filesystems to resolve will be a challenge. I don't think there is any way to provide such a guarantee as there is so many levels of cloning or dedup, many of which are totally invisible to the high level file system interface.