On Thu, Apr 20, 2017 at 1:15 AM, Andreas Dilger <adilger@xxxxxxxxx> wrote: > I recall there was a similar issue with GlusterFS assuming only 32-bit > readdir cookies on ext4, and stashing some information in the high bits, > but that broke when ext4 moved to 64-bit readdir cookies to avoid hash > collisions on "normal sized" directories (above ~32k entries). > > I'd agree that it is the filesystem's prerogative to use any/all of the > 64-bit inode number when it wants, and stacking filesystems shouldn't > try to usurp those bits for something else, only to suffer later on. Thought experiment: we extend statx with 128bit inode numbers; is it now the filesystems' prerogative to use all of the 128 bits for what it wants? See the flaw with that reasoning? Ideally we'd want dynamically sized inode numbers and we have that: file handles. But file handles do more than inode numbers and they are more heavyweight. > There is already some interest to add 64-bit inode numbers for ext4, and > it may allocate inode numbers sparsely, so just because the filesystem has > 2^33 inodes in it doesn't imply that the highest possible inum is 2^33, > but could instead be 2^48 or something else entirely. Exactly. I'm not saying we should limit filesystems use of MSB's but that filesystems should be able to say that they will use at max say 56 bits or whatever. They would be free to say they use all 64, but that would limit their use in stacking filesystems so they may not want to do that. Is that not reasonable? Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
