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 Wed, May 08, 2024 at 04:47:32AM -0700, Christoph Hellwig wrote:
> 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.

I guess we could make it really obvious by allocating range in the
mapping starting at MAX_FILEOFF and going downwards.  Chances are pretty
good that with the xattr info growing upwards they're never going to
meet.

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

Hammer?  All I've got is a big block of cheese. :P

FWIW the fsverity code seems to cut us off at U32_MAX bytes of merkle
data so that's going to be the limit until they rev the ondisk format.

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

Well right now they can't be used by attrs because xfs_dablk_t isn't big
enough to fit a larger value.  The dangerous part here is that the code
silently truncates the outparam of xfs_bmap_first_unused, so I'll fix
that too.

--D




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux