From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Cc: Christoph Hellwig <hch@lst.de>
Subject: [PATCH v2 0/7] btrfs: read-repair rework based on bitmap
Date: Wed, 25 May 2022 18:59:10 +0800 [thread overview]
Message-ID: <cover.1653476251.git.wqu@suse.com> (raw)
This is the bitmap version revivied, and based on Christoph's
cleanup series.
The branch can be feteched from my repo:
https://github.com/adam900710/linux/tree/read_repair
Changelog:
v2:
- Still go bitmap version to get batched submission
- Instead of using the old failed bio to hold all the pages, here we
use an oridnary bio to hold only the corrupted sectors.
- Unlike previous bitmap version, this time no memory allocation
The needed bitmap will be on-stack, and only limit to 32bits.
- Go synchronous submission for read and write
- Only use bitmap for the corrupted range.
Unlike previous version, which allocate bio for the whole bio.
That's a waste of memory.
- btrfs_read_repair_sector() will submit the existing repair early
For uncontinuous new sector or if we have reached size limit
(due to bitmap size limit, now it's 128K for 4K sectorsize).
This allow us to use fixed bitmap size.
The core function is still btrfs_read_repair_finish().
But now, btrfs_read_repair_finish() either get called without any
corrupted sectors, or it will only face a continuous range of corrupted
sectors.
Then we handle the range by iterating all the remaining mirrors.
For each mirror we go:
1) Try to add current bad sector into our io_bio.
If our io_bio is not continuous, we just submit current io_bio and
wait for it.
Then add the new sector into it.
2) If the io_bio is not empty, submit it.
By 1) and 2), we will read all bad sectors from the new mirror.
3) Check if the data is fine and update our ctrl::bad_bitmap
We either end with all sectors repaired, or all mirrors exhausted.
The advantage of bitmap method is, we only try at most (num_copies - 1)
times, no matter the corruption pattern.
On the other hand, for the worst case we're still doing sector by sector
repair.
For the best case (aka, continuous corruption cases), we still do
batched bio submission, thus still way better than sector-by-sector
repair.
Furthermore, all loops in the code are regular for() loops, no hacking
on how we loop.
But I have to admit, even the repair_from_mirror() and
btrfs_read_repair_finish() is super easy to read, the details on bio
page adding and submission are all hidden into io_add_or_submit() and
btrfs_read_repair_add_sector().
Although it has better worst case performance, it's no better than
sector-by-sector repair in worst case scenario.
Cc: Christoph Hellwig <hch@lst.de>
Christoph Hellwig (1):
btrfs: add a btrfs_map_bio_wait helper
Qu Wenruo (6):
btrfs: save the original bi_iter into btrfs_bio for buffered read
btrfs: make repair_io_failure available outside of extent_io.c
btrfs: introduce new read-repair infrastructure
btrfs: make buffered read path to use the new read repair
infrastructure
btrfs: make direct io read path to use the new read repair
infrastructure
btrfs: remove io_failure_record infrastructure completely
fs/btrfs/Makefile | 2 +-
fs/btrfs/btrfs_inode.h | 5 -
fs/btrfs/extent-io-tree.h | 15 --
fs/btrfs/extent_io.c | 436 +++--------------------------------
fs/btrfs/extent_io.h | 28 +--
fs/btrfs/inode.c | 60 ++---
fs/btrfs/read-repair.c | 328 ++++++++++++++++++++++++++
fs/btrfs/read-repair.h | 48 ++++
fs/btrfs/volumes.c | 21 ++
fs/btrfs/volumes.h | 2 +
include/trace/events/btrfs.h | 1 -
11 files changed, 458 insertions(+), 488 deletions(-)
create mode 100644 fs/btrfs/read-repair.c
create mode 100644 fs/btrfs/read-repair.h
--
2.36.1
next reply other threads:[~2022-05-25 10:59 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-25 10:59 Qu Wenruo [this message]
2022-05-25 10:59 ` [PATCH v2 1/7] btrfs: save the original bi_iter into btrfs_bio for buffered read Qu Wenruo
2022-05-25 10:59 ` [PATCH v2 2/7] btrfs: make repair_io_failure available outside of extent_io.c Qu Wenruo
2022-05-25 10:59 ` [PATCH v2 3/7] btrfs: add a btrfs_map_bio_wait helper Qu Wenruo
2022-05-25 10:59 ` [PATCH v2 4/7] btrfs: introduce new read-repair infrastructure Qu Wenruo
2022-05-26 3:06 ` Qu Wenruo
2022-05-26 7:30 ` Christoph Hellwig
2022-05-26 7:37 ` Qu Wenruo
2022-05-26 7:45 ` Christoph Hellwig
2022-05-26 7:52 ` Qu Wenruo
2022-05-26 8:00 ` Christoph Hellwig
2022-05-26 8:07 ` Qu Wenruo
2022-05-26 8:17 ` Christoph Hellwig
2022-05-26 8:26 ` Qu Wenruo
2022-05-26 8:28 ` Christoph Hellwig
2022-05-26 8:49 ` Qu Wenruo
2022-05-26 8:54 ` Christoph Hellwig
2022-05-26 9:13 ` Qu Wenruo
2022-05-27 8:10 ` Christoph Hellwig
2022-05-25 10:59 ` [PATCH v2 5/7] btrfs: make buffered read path to use the new read repair infrastructure Qu Wenruo
2022-05-25 10:59 ` [PATCH v2 6/7] btrfs: make direct io " Qu Wenruo
2022-05-25 10:59 ` [PATCH v2 7/7] btrfs: remove io_failure_record infrastructure completely Qu Wenruo
2022-05-25 14:55 ` [PATCH v2 0/7] btrfs: read-repair rework based on bitmap 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=cover.1653476251.git.wqu@suse.com \
--to=wqu@suse.com \
--cc=hch@lst.de \
--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