On Wed, Sep 01, 2021 at 11:22:51AM -0400, J. Bruce Fields wrote: > It's stronger than "a little more entropy". We know enough about how > the numbers being XOR'd grow to know that collisions are only going to > happen in some extreme use cases. (If I understand correctly.) Do we know that a malicious attacker can't reproduce the collisions? Because that is the case to worry about. > > into the inode number is a good enough band aid (and I strongly > > disagree with that), do it inside btrfs for every place they report > > the inode number. There is nothing NFS-specific about that. > > Neil tried something like that: > > https://lore.kernel.org/linux-nfs/162761259105.21659.4838403432058511846@xxxxxxxxxxxxxxxxxxxxx/ > > "The patch below, which is just a proof-of-concept, changes > btrfs to report a uniform st_dev, and different (64bit) st_ino > in different subvols." > > (Though actually you're proposing keeping separate st_dev?) No, I'm not suggestion to keep a separate st_dev in that case. So the above scheme looks like the most reasonable (or least unreasonable) of the approaches I've seen so far. I have to admit I've only noticed it now given how deep it was hidden in a thread that I only followed bit while on vacation. > I looked back through a couple threads to try to understand why we > couldn't do that (on new filesystems, with a mkfs option to choose new > or old behavior) and still don't understand. But the threads are long. > > There are objections to a new mount option (which seem obviously wrong; > this should be a persistent feature of the on-disk filesystem). Yes. Anything like this needs to be persisted. But a mount option might still be a reasonable way to set that persistent flag.
