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 <[email protected]> > > 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. _______________________________________________ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
