From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 0/4] btrfs: cleanups and preparation for the incoming RAID56J features
Date: Fri, 13 May 2022 16:34:27 +0800 [thread overview]
Message-ID: <cover.1652428644.git.wqu@suse.com> (raw)
Since I'm going to introduce two new chunk profiles, RAID5J and RAID6J
(J for journal), if we're relying on ad-hoc if () else if () branches to
calculate thing like number of p/q stripes, it will cause a lot of
problems.
In fact, during my development, I have hit tons of bugs related to this.
One example is alloc_rbio(), it will assign rbio->nr_data, if we forgot
to update the check for RAID5 and RAID6 profiles, we will got a bad
nr_data == num_stripes, and screw up later writeback.
90% of my suffering comes from such ad-hoc usage doing manual checks on
RAID56.
Another example is, scrub_stripe() which due to the extra per-device
reservation, @dev_extent_len is no longer the same the data stripe
length calculated from extent_map.
So this patchset will do the following cleanups preparing for the
incoming RAID56J (already finished coding, functionality and on-disk
format are fine, although no journal yet):
- Calculate device stripe length in-house inside scrub_stripe()
This removes one of the nasty mismatch which is less obvious.
- Use btrfs_raid_array[] based calculation instead of ad-hoc check
The only exception is scrub_nr_raid_mirrors(), which has several
difference against btrfs_num_copies():
* No iteration on all RAID6 combinations
No sure if it's planned or not.
* Use bioc->num_stripes directly
In that context, bioc is already all the mirrors for the same
stripe, thus no need to lookup using btrfs_raid_array[].
With all these cleanups, the RAID56J will be much easier to implement.
Qu Wenruo (4):
btrfs: remove @dev_extent_len argument from scrub_stripe() function
btrfs: use btrfs_chunk_max_errors() to replace weird tolerance
calculation
btrfs: use btrfs_raid_array[] to calculate the number of parity
stripes
btrfs: use btrfs_raid_array[].ncopies in btrfs_num_copies()
fs/btrfs/raid56.c | 10 ++--------
fs/btrfs/raid56.h | 12 ++----------
fs/btrfs/scrub.c | 13 +++++++------
fs/btrfs/volumes.c | 35 +++++++++++++++++++++--------------
fs/btrfs/volumes.h | 2 ++
5 files changed, 34 insertions(+), 38 deletions(-)
--
2.36.1
next reply other threads:[~2022-05-13 8:34 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-13 8:34 Qu Wenruo [this message]
2022-05-13 8:34 ` [PATCH 1/4] btrfs: remove @dev_extent_len argument from scrub_stripe() function Qu Wenruo
2022-05-13 8:47 ` Johannes Thumshirn
2022-05-13 8:34 ` [PATCH 2/4] btrfs: use btrfs_chunk_max_errors() to replace weird tolerance calculation Qu Wenruo
2022-05-13 8:45 ` Johannes Thumshirn
2022-05-13 8:34 ` [PATCH 3/4] btrfs: use btrfs_raid_array[] to calculate the number of parity stripes Qu Wenruo
2022-05-13 8:56 ` Johannes Thumshirn
2022-05-13 8:34 ` [PATCH 4/4] btrfs: use btrfs_raid_array[].ncopies in btrfs_num_copies() Qu Wenruo
2022-05-13 9:15 ` Johannes Thumshirn
2022-05-13 9:22 ` Qu Wenruo
2022-05-13 9:24 ` Johannes Thumshirn
2022-05-13 9:33 ` Qu Wenruo
2022-05-13 11:38 ` [PATCH 0/4] btrfs: cleanups and preparation for the incoming RAID56J features David Sterba
2022-05-13 12:21 ` Qu Wenruo
2022-05-13 15:14 ` Forza
2022-05-13 22:58 ` Qu Wenruo
2022-06-15 11: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=cover.1652428644.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.