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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[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