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, Apr 30, 2024 at 11:53:00PM -0700, Christoph Hellwig wrote:
> This and the header hacks suggest to me that shoe horning the fsverity
> blocks into attrs just feels like the wrong approach.
> 
> They don't really behave like attrs, they aren't key/value paris that
> are separate, but a large amount of same sized blocks with logical
> indexing.  All that is actually nicely solved by the original fsverity
> used by ext4/f2fs, while we have to pile workarounds ontop of
> workarounds to make attrs work.

Taking this a bit further:  If we want to avoid the problems associated
with the original scheme, mostly the file size limitation, and the (IMHO
more cosmetic than real) confusion with post-EOF preallocations, we
can still store the data in the attr fork, but not in the traditional
attr format.  The attr fork provides the logical index to physical
translation as the data fork, and while that is current only used for
dabtree blocks and remote attr values, that isn't actually a fundamental
requirement for using it.

All the attr fork placement works through xfs_bmap_first_unused() to
find completely random free space in the logic address space.

Now if we reserved say the high bit for verity blocks in verity enabled
file systems we can simply use the bmap btree to do the mapping from
the verity index to the on-disk verify blocks without any other impact
to the attr code.




[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