From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 0/8] btrfs: raid56: use submit-and-wait method to handle raid56 writes
Date: Wed, 26 Oct 2022 13:06:24 +0800 [thread overview]
Message-ID: <cover.1666760699.git.wqu@suse.com> (raw)
Currently btrfs raid56 is have many and very chaotic function entrances:
- full_stripe_write()
For full stripe write, will try to lock the full stripe and then do
the write.
- finish_rmw()
For rbio which holds the full stripe lock, only do the writes, for
either full stripe write, or sub-stripe write with cached rbio.
- raid56_rmw_stripe()
For sub-stripe write which owns the full stripe lock.
Furthermore we are using endio functions to go the next stage of the
work, it's really hard to properly follow the workflow.
The truth is, full-stripe is just a subset of a full RMW cycle, there
really not that much difference to treat full-stripe that differently
(except skip the plug).
This patchset will rework the raid56 write path (recover and scrub path
is not touched yet) by:
- Introduce a main function for raid56 writes
The main function will be called run_one_write_rbio(), and it always
executed in rmw_worker workqueue.
- Unified handling for all writes (full/sub-stripe, cached/non-cached,
degraded or not)
For full stripe write, it skips the read, and go into write part
directly.
For sub-stripe write, we will try to read the missing sectors first,
and wait for it (we may not read anything if it's cached).
Then check if we have some missing devices for the above read.
If so, do recovery first.
Finally we have everything needed, can submit the write bios, and wait
for the write to finish.
- No more need for end_io_work
Since we don't rely on endio functions to jump to the next step.
Unfortunately rbio::end_io_work can only be removed when recovery
and scrub path are also migrated to the new single main thread way.
By this, we have unified entrance for all raid56 writes, and no extra
jumping/workqueue mess to interrupt the workflow.
This would make later destructive RMW fix much easier to add, as the
timing of each step in RMW cycle should be very easy to grasp.
Thus I hope this series can be merged before the previous RFC series of
destructive RMW fix.
Qu Wenruo (8):
btrfs: raid56: extract the vertical stripe recovery code into
recover_vertical()
btrfs: raid56: extract the pq generation code into a helper
btrfs: raid56: introduce a new framework for RAID56 writes
btrfs: raid56: implement the read part for run_one_write_rbio()
btrfs: raid56: implement the degraded write for run_one_write_rbio()
btrfs: raid56: implement the write submission part for
run_one_write_bio()
btrfs: raid56: implement raid56_parity_write_v2()
btrfs: raid56: switch to the new run_one_write_rbio()
fs/btrfs/raid56.c | 1199 +++++++++++++++++++++++++++------------------
fs/btrfs/raid56.h | 4 +
2 files changed, 727 insertions(+), 476 deletions(-)
--
2.38.1
next reply other threads:[~2022-10-26 5:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-26 5:06 Qu Wenruo [this message]
2022-10-26 5:06 ` [PATCH 1/8] btrfs: raid56: extract the vertical stripe recovery code into recover_vertical() Qu Wenruo
2022-10-26 5:06 ` [PATCH 2/8] btrfs: raid56: extract the pq generation code into a helper Qu Wenruo
2022-10-26 5:06 ` [PATCH 3/8] btrfs: raid56: introduce a new framework for RAID56 writes Qu Wenruo
2022-10-26 5:06 ` [PATCH 4/8] btrfs: raid56: implement the read part for run_one_write_rbio() Qu Wenruo
2022-10-26 5:06 ` [PATCH 5/8] btrfs: raid56: implement the degraded write " Qu Wenruo
2022-10-26 5:06 ` [PATCH 6/8] btrfs: raid56: implement the write submission part for run_one_write_bio() Qu Wenruo
2022-10-26 5:06 ` [PATCH 7/8] btrfs: raid56: implement raid56_parity_write_v2() Qu Wenruo
2022-10-26 5:06 ` [PATCH 8/8] btrfs: raid56: switch to the new run_one_write_rbio() Qu Wenruo
2022-10-31 1:07 ` Qu Wenruo
2022-10-31 16:48 ` David Sterba
2022-10-31 23:25 ` Qu Wenruo
2022-10-31 7:39 ` [PATCH 0/8] btrfs: raid56: use submit-and-wait method to handle raid56 writes 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.1666760699.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;
as well as URLs for NNTP newsgroup(s).