All of lore.kernel.org
 help / color / mirror / Atom feed
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


             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.