Re: [RFC] Directly mapped xattr data & fs-verity

[Christoph Hellwig <hch@lst.de>]

On Mon, Jan 06, 2025 at 09:56:51PM +0100, Andrey Albershteyn wrote:
> On 2025-01-06 16:42:12, Christoph Hellwig wrote:
> > I've not looked in details through the entire series, but I still find
> > all the churn for trying to force fsverity into xattrs very counter
> > productive, or in fact wrong.
> 
> Have you checked
> 	[PATCH] xfs: direct mapped xattrs design documentation [1]?
> It has more detailed argumentation of this approach.

It assumes verity must be stored in the attr fork and then justifies
complexity by that.

> > xattrs are for relatively small variable sized items where each item
> > has it's own name.
> 
> Probably, but now I'm not sure that this is what I see, xattrs have
> the whole dabtree to address all the attributes and there's
> infrastructure to have quite a lot of pretty huge attributes.

fsverity has a linear mapping.  The only thing you need to map it
is the bmap btree.  Using the dabtree helps nothing with the task
at hand, quite to the contrary it makes the task really complex.
As seen both by the design document and the code.

> Taking 1T file we will have about 1908 4k merkle tree blocks ~8Mb,
> in comparison to file size, I see it as a pretty small set of
> metadata.

And you could easily map them using a single extent in the bmap
btree with no overhead at all.  Or a few more if there isn't enough
contiguous freespace.

> 
> > fsverity has been designed to be stored beyond
> > i_size inside the file.
> 
> I think the only requirement coming from fs-verity in this regard is
> that Merkle blocks are stored in Pages. This allows for PG_Checked
> optimization. Otherwise, I think it doesn't really care where the
> data comes from or where it is.

I'm not say it's a requirement.  I'm saying it's been designed with
that in mind.  In other words it is a very natural fit.  Mapping it
to some kind of xattrs is not.

> Yes, that's one of the arguments in the design doc, we can possibly
> use it for mutable files in future. Not sure how feasible it is with
> post-EOF approach.

Maybe we can used it for $HANDWAVE is not a good idea.  Hash based
verification works poorly for mutable files, so we'd rather have
a really good argument for that.

> I don't really see the advantage or much difference of storing
> fs-verity post-i_size. Dedicating post-i_size space to fs-verity
> dosn't seem to be much different from changing xattr format to align
> with fs blocks, to me.

It is much simpler, and more storage efficient by doing away with the
need for the dabtree entries and your new remote-remote header.