Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH v3 0/4] btrfs: make read time repair to be only submitted for each corrupted sector
Date: Mon,  3 May 2021 10:08:52 +0800	[thread overview]
Message-ID: <20210503020856.93333-1-wqu@suse.com> (raw)

Btrfs read time repair has to handle two different cases when a corruption
or read failure is hit:
- The failed bio contains only one sector
  Then it only need to find a good copy

- The failed bio contains several sectors
  Then it needs to find which sectors really need to be repaired

But this different behaviors are not really needed, as we can teach btrfs
to only submit read repair for each corrupted sector.
By this, we only need to handle the one-sector corruption case.

This not only makes the code smaller and simpler, but also benefits subpage,
allow subpage case to use the same infrastructure.

For current subpage code, we hacked the read repair code to make full
bvec read repair, which has less granularity compared to regular sector
size.

The code is still based on subpage branch, but can be forward ported to
non-subpage code basis with minor conflicts.

Changelog:
v2:
- Split the original patch
  Now we have two preparation patches, then the core change.
  And finally a cleanup.

- Fix the uninitialize @error_bitmap when the bio read fails.

v3:
- Fix the return value type mismatch in repair_one_sector()
  An error happens in v2 patch split, which can lead to hang when
  we can't repair the error.

Qu Wenruo (4):
  btrfs: remove the dead branch in btrfs_io_needs_validation()
  btrfs: make btrfs_verify_data_csum() to return a bitmap
  btrfs: submit read time repair only for each corrupted sector
  btrfs: remove io_failure_record::in_validation

 fs/btrfs/ctree.h     |   4 +-
 fs/btrfs/extent_io.c | 262 +++++++++++++++++++------------------------
 fs/btrfs/extent_io.h |   4 +-
 fs/btrfs/inode.c     |  19 +++-
 4 files changed, 134 insertions(+), 155 deletions(-)

-- 
2.31.1


             reply	other threads:[~2021-05-03  2:09 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-03  2:08 Qu Wenruo [this message]
2021-05-03  2:08 ` [PATCH v3 1/4] btrfs: remove the dead branch in btrfs_io_needs_validation() Qu Wenruo
2021-05-03 17:05   ` David Sterba
2021-05-03 23:39     ` Qu Wenruo
2021-05-10 20:14   ` David Sterba
2021-05-10 23:56     ` Qu Wenruo
2021-05-11 11:27       ` David Sterba
2021-05-03  2:08 ` [PATCH v3 2/4] btrfs: make btrfs_verify_data_csum() to return a bitmap Qu Wenruo
2021-05-03  2:08 ` [PATCH v3 3/4] btrfs: submit read time repair only for each corrupted sector Qu Wenruo
2021-05-10 20:32   ` David Sterba
2021-05-11  1:42     ` Qu Wenruo
2021-05-11 11:35       ` David Sterba
2021-05-03  2:08 ` [PATCH v3 4/4] btrfs: remove io_failure_record::in_validation Qu Wenruo
2021-05-10 20:41 ` [PATCH v3 0/4] btrfs: make read time repair to be only submitted for each corrupted sector David Sterba
2021-05-11  1:07   ` Qu Wenruo
2021-05-11 11:59     ` David Sterba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210503020856.93333-1-wqu@suse.com \
    --to=wqu@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox