Re: [f2fs-dev] [PATCH 4/6] fsverity: use a hashtable to find the fsverity_info

Christoph Hellwig
2026-01-20T07:35:53Z

On Mon, Jan 19, 2026 at 11:05:36AM -0800, Eric Biggers wrote:
> On Mon, Jan 19, 2026 at 07:22:45AM +0100, Christoph Hellwig wrote:
> > Use the kernel's resizable hash table to find the fsverity_info. This
> > way file systems that want to support fsverity don't have to bloat
> > every inode in the system with an extra pointer. The tradeoff is that
> > looking up the fsverity_info is a bit more expensive now, but the main
> > operations are still dominated by I/O and hashing overhead.
> >
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
>
> Has anything changed from my last feedback at
> https://lore.kernel.org/linux-fsdevel/20250810170311.GA16624@sol/ ?
>
> Any additional data on the cycles and icache footprint added to data
> verification? The preliminary results didn't look all that good to me.

Nothing has changed, as as expected by then and now the lookup overhead
is completely dwarfed by other parts of the read, even when the
data and hashes are already cached. Of course if you look into the lookup
in itself, any kind of data structure will be significantly more expensive
than a pointer dereference and nothing will change that.

> It also seems odd to put this in an "fsverity optimzations and speedups"
> patchset, given that it's the opposite.

It optimizes the memory usage and doesn't require bloating the inode
for new file systems adding fsverity support. size of the inode is
a major concern, and is even more so for a feature that is not
commonly used and then not for most files.