On Wed, Jan 28, 2026 at 02:56:02PM -0800, Eric Biggers wrote: > On Wed, Jan 28, 2026 at 04:26:20PM +0100, Christoph Hellwig wrote: > > Currently all reads of the fsverity hashes is kicked off from the data > > I/O completion handler, leading to needlessly dependent I/O. This is > > worked around a bit by performing readahead on the level 0 nodes, but > > still fairly ineffective. > > > > Switch to a model where the ->read_folio and ->readahead methods instead > > kick off explicit readahead of the fsverity hashed so they are usually > > available at I/O completion time. > > > > For 64k sequential reads on my test VM this improves read performance > > from 2.4GB/s - 2.6GB/s to 3.5GB/s - 3.9GB/s. The improvements for > > random reads are likely to be even bigger. > > > > Signed-off-by: Christoph Hellwig <[email protected]> > > Acked-by: David Sterba <[email protected]> [btrfs] > > Unfortunately, this patch causes recursive down_read() of > address_space::invalidate_lock. How was this meant to work?
It worked by the chances that multiple down_read generally work. Except when they don't and we have a write queued up in between, but nothing in xfstests hits that. I'll look into reworking it to avoid that. _______________________________________________ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
