On Sat, Aug 28, 2021 at 09:05:08AM +1000, NeilBrown wrote: > There doesn't seem to be any other option - and this is still an > improvement over the current behaviour. > > Collisions should still be quite a few years away, and there is hope > that the btrfs developers will take action before then to provide some > certainty. Not much hope, but some. I think that is a very dangerous assumption. Given how every inode allocation tends to be somewhat predictable I'm also really worried that this actually opens up an attach vector. Last but not least I also very much disagree with any of the impact to common code. Most importantly the kstat structure, which exist to support the stat family of system calls and not as a side channel for NFS file handles (nevermind that it is hidden in a nfs patch and didn't even Cc the fsdevel list), but also all the impact to the generic nfsd code for this very broken concept. If you want to support such a scheme in btrfs as the lesser of evils (which I disagree with), please make sure it stays self-contained in the btrfs specific file handle encoding and decoding.
