On Wed, Mar 24, 2021 at 9:43 AM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > On Wed, Mar 24, 2021 at 08:53:25AM +0200, Amir Goldstein wrote: > > > This also means that userspace can be entirely filesystem agnostic > > > and it doesn't need to rely on parsing proc files to translate > > > ephemeral mount IDs to paths, statvfs() and hoping that f_fsid is > > > stable enough that it doesn't get the destination wrong. It also > > > means that fanotify UAPI probably no longer needs to supply a > > > f_fsid with the filehandle because it is built into the > > > filehandle.... > > > > > > > That is one option. Let's call it the "bullet proof" option. > > > > Another option, let's call it the "pragmatic" options, is that you accept > > that my patch shouldn't break anything and agree to apply it. > > Your patch may very well break something. Most Linux file systems do > store the dev_t in the fsid and userspace may for whatever silly > reasons depend on it. > I acknowledge that. I do not claim that my change carries zero risk of breakage. However, if such userspace dependency exists, it would break on ext4, btrfs, ocsf2, ceph and many more fs, so it would have to be a dependency that is tightly coupled with a specific fs. The probability of that is rather low IMO. I propose an opt-in mount option "-o fixed_fsid" for this behavior to make everyone sleep better. > Also trying to use the fsid for anything persistent is plain stupid, > 64-bits are not enough entropy for such an identifier. You at least > need a 128-bit UUID-like identifier for that. > That's a strong claim to make without providing statistical analysis and the description of the use case. The requirement is for a unique identifier of a mounted fs within a single system. > So I think this whole discussion is going in the wrong direction. > Is exposing a stable file system identifier useful? Yes, for many > reasons. Is repurposing the fsid for that a good idea? Hell no. Again. Strong reaction not backed up by equally strong technical arguments. I am not at all opposed to a new API for stable FS_HANDLE, but no, I am not going to offer writing this new API myself at this point. Applications that use statfs() to identify a filesystem may very well already exist in the wild, so the fixed_fsid discussion is independent of the new API. Considering the fact that many relevant filesystems do provide a stable f_fsid and considering the fact that a blockdev number of devices that are instantiated at boot time are often practically stable, the users of those applications could be unaware of the instability of f_fsid or maybe they can live with it. I find it hard to argue with the "all-or-nothing" attitude in the reaction to my proposed change. What I propose is an opt-in mount option "-o fixed_fsid". IMO, NACKing this proposal is not going to improve anything for anyone, but I don't know what more to say. Thanks, Amir.
