On Tue, Jul 30, 2024 at 12:31:57PM +1000, Dave Chinner wrote: > I don't think you can make such a simplistic delineation, because > there's more than one issue at play here. > > 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. That's fair, but the first is the problem I think is more important, because there are existing programs which are depending on st_dev/st_ino as being a reliable way of detecting uniqueness --- and if this breas, file data may get corrpted, or the dyanmic linker will assume that two unrelated shared libraries are actually the same, with hilarity then ensuing --- because an interface which is guaranteed by decade of Unix history, and POSIX, is broken by some Linux file systems. > The second is that {dev,ino} is being used to disambiguate paths > that point to hardlinked inodes for the purposes of identifying > and optimising access and replication of shared (i.e. non-unique) > file data. > > This works on traditional filesystems like ext4, but fails badly on > filesystem that support FICLONERANGE (XFS, btrfs, NFS, CIFS, > bcachefs, etc) because cloned files have unique inodes but > non-unique data. That's a problem, yes --- but it's a previously unsolved problem, and the failure will cause inefficiency, but it doesn't actually cause data corruption. It's also a very hard problem, especially if we're considering the full, general FICLONERANGE interface, where an arbitrary subset of blocks at one offset, might be cloned at a completely different offset in a different file, and where a single file might have cloned ranges from a dozens of other files. How this information would be communicated to userspace, so they could copy a directory hierarchy without an increased expansion is a hard problem. Given that we have a simple solution (filehandles) to fix a problem where false positives causes lost data or core dumps, let's solve the simple problem and try to get it standardized acrossed operating systems beyond Linux, and in parallel, we can try to figure out a much more complicated interface to solve this other problem. - Ted