Re: [PATCH 18/26] xfs: use merkle tree offset as attr hash

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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..





[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux