Snapshots, inodes, and filesystem identifiers
Snapshots, inodes, and filesystem identifiers
Posted May 19, 2022 4:27 UTC (Thu) by neilbrown (subscriber, #359)Parent article: Snapshots, inodes, and filesystem identifiers
I wonder what Bruce might have meant by that. NFS doesn't export the statx system call, so it couldn't make the subvolume ID available to the client.
NFSd could mix the subvolume ID in with the filesystem ID, but that would cause subvolume names - which are sometimes considered to be private - to be publicly visible on any client used to access them.
NFSd could mix it in to the inode number. That only provides a 99.999+% solution, which isn't perfect enough for some. However it is the *only* credible solution for those "POSIX-following tools".
Really, we don't need to export any new information. We already export the filehandle to user-space, and that is even exported over NFS.
We just need to change applications to access and depend on the filehandle (when available) instead of depending on the inode number.
(I almost wrote a patch for find, but I lost interest.....)
Posted May 22, 2022 2:03 UTC (Sun)
by bfields (subscriber, #19510)
[Link] (2 responses)
> I wonder what Bruce might have meant by that.
Yeah, FWIW, I took a couple minutes to look through old email and I can't figure out what that's referring to.
Posted May 22, 2022 13:16 UTC (Sun)
by jake (editor, #205)
[Link] (1 responses)
It's certainly possible that I misunderstood Josef, so maybe that's where the disconnect is ...
jake
Posted May 23, 2022 21:07 UTC (Mon)
by bfields (subscriber, #19510)
[Link]
Snapshots, inodes, and filesystem identifiers
Snapshots, inodes, and filesystem identifiers
It is a bit of a game of "telephone", I wouldn't be too quick to rule out the possibility that I said something dumb....
Snapshots, inodes, and filesystem identifiers