On Mon, Jul 29, 2024 at 1:37 PM Florian Weimer <fweimer@xxxxxxxxxx> wrote: > > * Mateusz Guzik: > > > On Mon, Jul 29, 2024 at 12:57 PM Florian Weimer <fweimer@xxxxxxxxxx> wrote: > >> > >> * Mateusz Guzik: > >> > >> > On Mon, Jul 29, 2024 at 12:40:35PM +0200, Florian Weimer wrote: > >> >> * Mateusz Guzik: > >> >> > >> >> > On Mon, Jul 29, 2024 at 08:55:46AM +0200, Florian Weimer wrote: > >> >> >> It was pointed out to me that inode numbers on Linux are no longer > >> >> >> expected to be unique per file system, even for local file systems. > >> >> > > >> >> > I don't know if I'm parsing this correctly. > >> >> > > >> >> > Are you claiming on-disk inode numbers are not guaranteed unique per > >> >> > filesystem? It sounds like utter breakage, with capital 'f'. > >> >> > >> >> Yes, POSIX semantics and traditional Linux semantics for POSIX-like > >> >> local file systems are different. > >> > > >> > Can you link me some threads about this? > >> > >> Sorry, it was an internal thread. It's supposed to be common knowledge > >> among Linux file system developers. Aleksa referenced LSF/MM > >> discussions. > >> > > > > So much for open development :-P > > I found this pretty quickly, so it does seem widely known: > > [LSF TOPIC] statx extensions for subvol/snapshot filesystems & more > <https://lore.kernel.org/linux-fsdevel/2uvhm6gweyl7iyyp2xpfryvcu2g3padagaeqcbiavjyiis6prl@yjm725bizncq/> > Huh, thanks. > >> It's certainly much easier to use than name_to_handle_at, so it looks > >> like a useful option to have. > >> > >> Could we return a three-way comparison result for sorting? Or would > >> that expose too much about kernel pointer values? > >> > > > > As is this would sort by inode *address* which I don't believe is of > > any use -- the order has to be assumed arbitrary. > > Doesn't the order remain valid while the files remain open? Anything > else doesn't seem reasonable to expect anyway. > They will indeed remain stable in that setting, I am saying ordering may be different after a reboot or if there was some memory reclamation going on between restarts of the program. This is quite a difference from dev + ino combo not suffering these problems. That is to say I don't see what is the benefit of having the kernel provide a way to sort inodes in a way which can give different results. -- Mateusz Guzik <mjguzik gmail.com>
