On Mon, Aug 02, 2021 at 02:18:29PM +1000, NeilBrown wrote: > It think we need to bite-the-bullet and decide that 64bits is not > enough, and in fact no number of bits will ever be enough. overlayfs > makes this clear. Sure - let's go for broke and use XML. Oh, wait - it's 8 months too early... > So I think we need to strongly encourage user-space to start using > name_to_handle_at() whenever there is a need to test if two things are > the same. ... and forgetting the inconvenient facts, such as that two different fhandles may correspond to the same object. > I accept that I'm proposing some BIG changes here, and they might break > things. But btrfs is already broken in various ways. I think we need a > goal to work towards which will eventually remove all breakage and still > have room for expansion. I think that must include: > > - providing as-unique-as-practical inode numbers across the whole > filesystem, and deprecating the internal use of different device > numbers. Make it possible to mount without them ASAP, and aim to > make that the default eventually. > - working with user-space tool/library developers to use > name_to_handle_at() to identify inodes, only using st_ino > as a fall-back > - adding filehandles to various /proc etc files as needed, either > duplicating lines or duplicating files. And helping application which > use these files to migrate (I would *NOT* change the dev numbers in > the current file to report the internal btrfs dev numbers the way that > SUSE does. I would prefer that current breakage could be used to > motivate developers towards depending instead on fhandles). > - exporting subtree (aka subvol) id to user-space, possibly paralleling > proj_id in some way, and extending various tools to understand > subtrees > > Who's with me?? Cf. "Poe Law"...
