[PATCH 0/5] btrfs: scrub: fix the scrub performance regression caused by unnecessary extent/csum tree searchs

[Qu Wenruo <wqu@suse.com>]

Although patch "btrfs: scrub: fix grouping of read IO" fixed one of the
major performance regression of scrub, it still only get the performance
back to 2GiB/s, it's still only 66% of the old 3GiB/s.

During my local debug, I found that the data csum fulfilling by itself
can be a big bottleneck.
If I completely skip the data csum fulfilling, it can already improve
the performance to around 2.6GiB/s (but of course it makes no sense
without data csums).

This reminds me a big factor, since we're doing scrub in stripe unit,
it would cause a lot of more extent/csum tree search.

In fact, the old code is doing csum search for every 512KiB, while we're
doing the same search for every 64KiB, causing 8x increase in csum tree
search.

Thus this patch would reduce the extent/csum tree search by re-using the
paths.

This two points along would already improve the performance to a much
more acceptable 2.5GiB/s. (83% of the old performance).

And those two patches are small enough for backports.

The remaining 3 patches are mostly cleanups.

Qu Wenruo (5):
  btrfs: scrub: avoid unnecessary extent tree search preparing stripes
  btrfs: scrub: avoid unnecessary csum tree search preparing stripes
  btrfs: scrub: move write back of repaired sectors into 
    scrub_stripe_read_repair_worker()
  btrfs: scrub: don't go ordered workqueue for dev-replace
  btrfs: scrub: extract the stripe group submission into a helper

 fs/btrfs/file-item.c |  33 +++++----
 fs/btrfs/file-item.h |   6 +-
 fs/btrfs/raid56.c    |   4 +-
 fs/btrfs/scrub.c     | 156 +++++++++++++++++++++++++++++--------------
 4 files changed, 133 insertions(+), 66 deletions(-)

-- 
2.41.0