From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH v5 0/3] btrfs: make read time repair to be only submitted for each corrupted sector
Date: Wed, 12 May 2021 12:53:27 +0800 [thread overview]
Message-ID: <20210512045330.40329-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 without any extra
modification.
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.
v4:
- Fix a bug that end_page_read() get called twice for the same range
This happens when the corrupted sector has no extra copy, thus
btrfs_submit_read_repair() return -EIO, leaving both
btrfs_submit_read_repair() and end_bio_extent_readpage() to
call end_page_read() twice on the good copy.
Thankfully this only affects subpage.
- Fix a bug that sectors after unrepairable corruption are not released
Since btrfs_submit_read_repair() is responsible for the page release,
we can no longer just error out.
Or some ordered extent will not be able to finish.
- Remove patch "btrfs: remove the dead branch in btrfs_io_needs_validation()"
The cleanup will break bisect, as DIO can still generate cloned bio.
Thus remove it and let the final cleanup patch to handle everything.
- Apply the style fixes from David
v5:
- Fix a bug where we grab wrong fs_info from DIO page
Exposed by btrfs/215.
And for DIO case we don't need end_page_read() and extent unrelease
call at all.
- Unexport btrfs_submit_read_repair(), export btrfs_repair_one_sector()
Since DIO only needs to repair one sector, unexport
btrfs_submit_read_repair() and just export btrfs_repair_one_sector().
Qu Wenruo (3):
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 | 348 +++++++++++++++++++++----------------------
fs/btrfs/extent_io.h | 13 +-
fs/btrfs/inode.c | 27 ++--
4 files changed, 191 insertions(+), 201 deletions(-)
--
2.31.1
next reply other threads:[~2021-05-12 4:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-12 4:53 Qu Wenruo [this message]
2021-05-12 4:53 ` [PATCH v5 1/3] btrfs: make btrfs_verify_data_csum() to return a bitmap Qu Wenruo
2021-05-12 4:53 ` [PATCH v5 2/3] btrfs: submit read time repair only for each corrupted sector Qu Wenruo
2021-06-07 8:27 ` Qu Wenruo
2021-05-12 4:53 ` [PATCH v5 3/3] btrfs: remove io_failure_record::in_validation Qu Wenruo
2021-05-12 13:57 ` [PATCH v5 0/3] btrfs: make read time repair to be only submitted for each corrupted sector David Sterba
2021-05-13 16:45 ` 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=20210512045330.40329-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;
as well as URLs for NNTP newsgroup(s).