On Thu 22-02-24 06:27:14, Kent Overstreet wrote: > On Thu, Feb 22, 2024 at 12:01:38PM +0100, Jan Kara wrote: > > On Thu 22-02-24 04:42:07, Kent Overstreet wrote: > > > On Thu, Feb 22, 2024 at 10:14:20AM +0100, Miklos Szeredi wrote: > > > > On Wed, 21 Feb 2024 at 22:08, Josef Bacik <josef@xxxxxxxxxxxxxx> wrote: > > > > > > > > > > On Wed, Feb 21, 2024 at 04:06:34PM +0100, Miklos Szeredi wrote: > > > > > > On Wed, 21 Feb 2024 at 01:51, Kent Overstreet <kent.overstreet@xxxxxxxxx> wrote: > > > > > > > > > > > > > > Recently we had a pretty long discussion on statx extensions, which > > > > > > > eventually got a bit offtopic but nevertheless hashed out all the major > > > > > > > issues. > > > > > > > > > > > > > > To summarize: > > > > > > > - guaranteeing inode number uniqueness is becoming increasingly > > > > > > > infeasible, we need a bit to tell userspace "inode number is not > > > > > > > unique, use filehandle instead" > > > > > > > > > > > > This is a tough one. POSIX says "The st_ino and st_dev fields taken > > > > > > together uniquely identify the file within the system." > > > > > > > > > > > > > > > > Which is what btrfs has done forever, and we've gotten yelled at forever for > > > > > doing it. We have a compromise and a way forward, but it's not a widely held > > > > > view that changing st_dev to give uniqueness is an acceptable solution. It may > > > > > have been for overlayfs because you guys are already doing something special, > > > > > but it's not an option that is afforded the rest of us. > > > > > > > > Overlayfs tries hard not to use st_dev to give uniqueness and instead > > > > partitions the 64bit st_ino space within the same st_dev. There are > > > > various fallback cases, some involve switching st_dev and some using > > > > non-persistent st_ino. > > > > > > Yeah no, you can't crap multiple 64 bit inode number spaces into 64 > > > bits: pigeonhole principle. > > > > > > We need something better than "hacks". > > > > I agree we should have a better long-term plan than finding ways how to > > cram things into 64-bits inos. However I don't see a realistic short-term > > solution other than that. > > > > To explicit: Currently, tar and patch and very likely other less well-known > > tools are broken on bcachefs due to non-unique inode numbers. If you want > > ot fix them, either you find ways how bcachefs can cram things into 64-bit > > ino_t or you go and modify these tools (or prod maintainers or whatever) to > > not depend on ino_t for uniqueness. The application side of things isn't > > going to magically fix itself by us telling "bad luck, ino_t isn't unique > > anymore". > > My intent is to make a real effort towards getting better interfaces > going, prod those maintainers, _then_ look at adding those hacks (that > will necessarily be short term solutions since 64 bits is already > looking cramped). OK, fine by me :) So one thing is still not quite clear to me - how do you expect the INO_NOT_UNIQUE flag to be used by these apps? Do you expect them to use st_dev + st_ino by default and fall back to fsid + fhandle only when INO_NOT_UNIQUE is set? Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
