* 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/> >> 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. Thanks, Florian
