On Wed, May 01, 2024 at 09:42:07PM -0700, Christoph Hellwig wrote: > On Wed, May 01, 2024 at 03:35:19PM -0700, Darrick J. Wong wrote: > > Got a link? This is the first I've heard of this, but TBH I've been > > ignoring a /lot/ of things trying to get online repair merged (thank > > you!) over the past months... > > This was long before I got involved with repair :) > > Below is what I found in my local tree. It doesn't have a proper commit > log, so I probably only sent it out as a RFC in reply to a patch series > posting, most likely untested: > > commit c11dcbe101a240c7a9e9bae7efaff2779d88b292 > Author: Christoph Hellwig <hch@xxxxxx> > Date: Mon Oct 16 14:14:11 2023 +0200 > > fsverity block interface That RFC patch doesn't take into account the bitmap, but the overall idea does seem to work. I've had a go at the block-based Merkle tree caching support at https://lore.kernel.org/fsverity/20240515015320.323443-1-ebiggers@xxxxxxxxxx. Let me know what you think. (The one thing I'm not a huge fan of is the indirect call on the drop path. Previously, it wasn't necessary for filesystems using page based caching. This hopefully is a minor point, but I'm not sure, since unfortunately indirect calls are atrociously expensive these days -- especially on x86. Having the single read_block / drop_block interface does seem like the right solution, though. We could always optimize the pagecache-based drop to a direct call later, while conceptually still having it be an implementation of the same interface.) - Eric
