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
