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!

@puckipedia @edef overlayFS, but both filesystems have to be ZFS to get around the inode problem

@wxcafe @puckipedia docker used to refuse to use overlayfs if you ran ZFS (falling back to .. dm-thin and ext4), though i'm unsure of the underlying details

@edef @puckipedia oh god I was expecting to see a hardcoded list of supported filesystems so much

@wxcafe @puckipedia no idea, i'd never use overlayfs on a ZFS lowerdir though

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.