today i thought to myself "gosh. i can't think of a way to write a POSIX overlay filesystem that doesn't produce absolutely horrifyingly nonsensical inode semantics"
thinking that perhaps, i might just be very dumb, i opened the overlayfs documentation page
it turns out that the answer is "they are indeed", and the documentation claims this is alright because "many applications and tools ignore these values and will not be affected", which somehow fails to soothe me

@edef overlayfs, but all the parts have to be on the same file system, to ensure inodes don't overlap :icon_twisted:

though I am wondering, what kind of tools don't ignore inodes?

@puckipedia avoiding inode overlap is relatively easy (inodes are 64-bit now, and you can almost definitely spare a bit)
what's harder is having *consistent* inodes, as opposed to having them flip over the moment you do open(.., O_RDWR)

@edef oh huh, ... I had no idea how large inodes were actually. but yeah, consistent inodes would be nice I guess?

@puckipedia you could plausibly store the inode number in an xattr on copyup, which would at least make stat return something consistent
it would break that one wacky syscall NFS uses to turn inodes back into file handles, but i can live with that

@puckipedia because you can't implement NFS connection recovery without absurd overhead otherwise!

Sign in to participate in the conversation

queer.af, your cosy queer space queer.af is a mastodon instance for those who are queer or queer-adjacent who would like a more pleasant social media experience.