Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 0/8] btrfs-progs: add RAID56 rebuild ability at read time
Date: Tue,  5 Apr 2022 20:48:22 +0800	[thread overview]
Message-ID: <cover.1649162174.git.wqu@suse.com> (raw)

This branch can be fetched from github:
https://github.com/adam900710/btrfs-progs/tree/raid56_rebuild

Please note that, the last time I check devel branch, the RAID56 warning
patch is not yet merged.

So this is based on the latest devel branch from github.

And since we're adding proper RAID56 repair ability, there is no need
for the patchset "btrfs-progs: check: avoid false alerts for --check-data-csum on RAID56"

This patchset is mostly to add the ability to properly read data/metadata
for RAID56 when mirror_num > 1.

[PROBLEMS]
There are several for current btrfs-progs:

- No RAID56 rebuild ability
  Thus for any mirror > 1 on RAID56, we will read the parity data
  straight, causing no way to recover.

- No unified logical read/write entrance
  We have various different functions, for read we have
  read_data_from_disk(), read_extent_data() and read_extent_from_disk().

  Unlike kernel, we have no btrfs_map_bio() to address everything.

  This makes adding RAID56 rebuild even hard.

[FIXES]
To address the problem, this patchset will:

- Cleanup and refactors
  Mostly to unify the logical read/write entrance.
  In patch 1~6, we will unify the logical read write entrances to
  only two functions:
  * read_extent_from_disk()
  * write_extent_to_disk()

  They will do the chunk mapping and stripe splitting.

- Add RAID56 read rebuild ability
  We already have RAID56 RMW for write path.
  Just add a new helper for mirror > 1 read on RAID56.

- A new test case
  In fact the same test case from previous RAID56 warning patchset.

Qu Wenruo (8):
  btrfs-progs: remove the unnecessary BTRFS_SUPER_INFO_OFFSET path for
    tree block read
  btrfs-progs: extract metadata restore read code into its own helper
  btrfs-progs: don't use write_extent_to_disk() directly
  btrfs-progs: use write_data_to_disk() to replace
    write_extent_to_disk()
  btrfs-progs: use read_data_from_disk() to replace
    read_extent_from_disk() and replace read_extent_data()
  btrfs-progs: remove extent_buffer::fd and extent_buffer::dev_bytes
  btrfs-progs: allow read_data_from_disk() to rebuild RAID56 using P/Q
  btrfs-progs: tests/fsck: add test case for data csum check on raid5

 btrfs-corrupt-block.c                         |  38 +---
 btrfs-map-logical.c                           |   5 +-
 btrfstune.c                                   |   3 +-
 check/main.c                                  |   2 +-
 check/mode-common.c                           |   4 +-
 cmds/restore.c                                |   4 +-
 image/main.c                                  |   2 +-
 kernel-shared/ctree.c                         |   5 +-
 kernel-shared/disk-io.c                       | 140 +++++--------
 kernel-shared/disk-io.h                       |   2 -
 kernel-shared/extent_io.c                     | 188 ++++++++++++------
 kernel-shared/extent_io.h                     |   9 +-
 kernel-shared/file.c                          |  20 +-
 kernel-shared/free-space-cache.c              |  20 +-
 kernel-shared/volumes.c                       |  39 ++--
 kernel-shared/volumes.h                       |   1 +
 .../056-raid56-false-alerts/test.sh           |  31 +++
 17 files changed, 277 insertions(+), 236 deletions(-)
 create mode 100755 tests/fsck-tests/056-raid56-false-alerts/test.sh

-- 
2.35.1


             reply	other threads:[~2022-04-05 15:01 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-05 12:48 Qu Wenruo [this message]
2022-04-05 12:48 ` [PATCH 1/8] btrfs-progs: remove the unnecessary BTRFS_SUPER_INFO_OFFSET path for tree block read Qu Wenruo
2022-04-05 12:48 ` [PATCH 2/8] btrfs-progs: extract metadata restore read code into its own helper Qu Wenruo
2022-04-05 12:48 ` [PATCH 3/8] btrfs-progs: don't use write_extent_to_disk() directly Qu Wenruo
2022-04-05 12:48 ` [PATCH 4/8] btrfs-progs: use write_data_to_disk() to replace write_extent_to_disk() Qu Wenruo
2022-04-05 12:48 ` [PATCH 5/8] btrfs-progs: use read_data_from_disk() to replace read_extent_from_disk() and replace read_extent_data() Qu Wenruo
2022-04-05 12:48 ` [PATCH 6/8] btrfs-progs: remove extent_buffer::fd and extent_buffer::dev_bytes Qu Wenruo
2022-04-05 12:48 ` [PATCH 7/8] btrfs-progs: allow read_data_from_disk() to rebuild RAID56 using P/Q Qu Wenruo
2022-04-05 12:48 ` [PATCH 8/8] btrfs-progs: tests/fsck: add test case for data csum check on raid5 Qu Wenruo
2022-04-08 21:16 ` [PATCH 0/8] btrfs-progs: add RAID56 rebuild ability at read time David Sterba
2022-04-11 15:01 ` David Sterba
2022-04-25 16:29   ` David Sterba
2022-04-25 22:38     ` Qu Wenruo

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.1649162174.git.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