Re: [PATCH RFC 2/2] btrfs: do data read repair in synchronous mode

[Christoph Hellwig <hch@infradead.org>]

On Fri, Mar 25, 2022 at 06:53:31PM +0800, Qu Wenruo wrote:
> > I'd suggest to at least submit all I/O in parallel.  Just put
> > a structure with an atomic_t and completion on the stack.  Start with
> > a recount of one, inc for each submit, and then dec after all
> > submissions and for each completion and only wake on the final dec.
> > That will make sure there is only one wait instead of one per copy.
> > 
> > Extra benefits for also doing this for all sectors, but that might be
> > a little more work.
> 
> Exactly the same plan B in my head.
> 
> A small problem is related to how to record all these corrupted sectors.
> 
> Using a on-stack bitmap would be the best, and it's feasible for x86_64
> at least.
> (256 bvecs = 256x4K pages = 256 sectors = 256bits).
> But not that sure for larger page size.
> As the same 256 bvecs can go 256x64K pages = 256 * 16 sectors, way too
> large for on-stack bitmap.
> 
> 
> If we go list, we need extra memory allocation, which can be feasible
> but less simple.

Just chunk it up so that only up to a reasonable bitmap size worth of
I/O is done at a time.