On 2024-07-29, Mateusz Guzik <mjguzik@xxxxxxxxx> wrote: > On Mon, Jul 29, 2024 at 12:57 PM Florian Weimer <fweimer@xxxxxxxxxx> wrote: > > > On Mon, Jul 29, 2024 at 12:40:35PM +0200, Florian Weimer wrote: > > >> > 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 To be clear, this wasn't _decided_ at LSF/MM, it was brought up as a topic. There is an LWN article about the session that mentions the issue[1]. My understanding is that the btrfs and bcachefs folks independently determined they cannot provide this guarantee. As far as I understand, the reason why is that inode number allocation on btree filesystems stores information about location and some other bits (maybe subvolumes) in the bits, making it harder to guarantee there will be no collisions. Don't quote me on that though, I'm sure they'll tell me I'm wrong when they wake up. :D As the article mentions, Kent Overstreet suggested trying to see how many things break if you build a kernel where all inode numbers are the same (my guess would be "very badly" -- aside from the classic problem of hardlink detection, a lot of programs key things by (dev, ino), and some inode numbers are guaranteed by the kernel for pseudo-filesystems like PROC_ROOT_INO). [1]: https://lwn.net/Articles/975444/ -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH <https://www.cyphar.com/>
Attachment:
signature.asc
Description: PGP signature
