On Tue, May 07, 2024 at 02:24:54PM -0700, Darrick J. Wong wrote: > Since we know the size of the merkle data ahead of time, we could also > preallocate space in the attr fork and create a remote ATTR_VERITY xattr > named "merkle" that points to the allocated space. Then we don't have > to have magic meanings for the high bit. Note that high bit was just an example, a random high offset might be a better choice, sized with some space to spare for the maximum verify data. > Will we ever have a merkle tree larger than 2^32-1 bytes in length? If > that's possible, then either we shard the merkle tree, or we have to rev > the ondisk xfs_attr_leaf_name_remote structure. If we did that would be yet another indicator that they aren't attrs but something else. But maybe I should stop banging that drum and agree that everything is a nail if all you got is a hammer.. :) > > I think we have to rev the format anyway, since with nrext64==1 we can > have attr fork extents that start above 2^32 blocks, and the codebase > will blindly truncate the 64-bit quantity returned by > xfs_bmap_first_unused. Or we decide the space above 2^32 blocks can't be used by attrs, and only by other users with other means of discover. Say the verify hashes..
