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. [1]: https://lore.kernel.org/linux-xfs/20250106154212.GA27933@xxxxxx/T/#m412549e0f3b6671a3bb9f1cb1c0967d504c06ef4 > > 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. 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. > 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. > We're creating a lot of overhead for trying > to map fsverity to an underlying storage concept that does not fit it > will. As fsverity protected files can't be written to there is no > chance of confusing fsverity blocks with post-EOF preallocation. 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. Regarding code overhead, I don't think it's that much. iomap interface could be used by any filesystem to read tree from post eof/anywhere else via ->iomap_begin. The directly mapped attribute data is a change of leaf format. Then, the fs-verity patchset itself isn't that huge. But yeah, this's probably more changes than post i_size. > > So please try to implement it just using the normal post-i_size blocks > and everything will become a lot simpler and cleaner even if the concept > of metadata beyond EOF might sound revolting (it still does to me to > some extent) > 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. -- - Andrey