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

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

 



On Mon, Jan 06, 2025 at 04:42:12PM +0100, 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.
> 
> xattrs are for relatively small variable sized items where each item
> has it's own name.  fsverity has been designed to be stored beyond
> i_size inside the file.  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.
> 
> 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 was wondering the same thing -- why not just put the merkle tree
blocks well past EOF and use the regular iomap readahead functions to
get the tree data read in bulk.  Plus you can do readahead optimization
that the fsverity code seems to want anyway.

Just be sure to put it well past EOF, since the current weird thing that
ext4 does (next ~64K after EOF) would seem to allow mmap reads of merkle
tree content for systems with really large base page sizes (e.g.
hexagon).

--D




[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