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

Andrey Albershteyn
2025-01-08T09:21:06Z

On 2025-01-07 17:50:57, Christoph Hellwig wrote:
> 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.

hmm, why? Not sure I have an understanding of this

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

I see.

--
- Andrey