From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH v2 0/3] btrfs: raid56: reduce unnecessary parity writes
Date: Wed, 1 Jun 2022 09:59:05 +0800 [thread overview]
Message-ID: <cover.1654048515.git.wqu@suse.com> (raw)
[Changelog]
v2:
- Cleanup the data bitmap after all the IO of the full stripe finished
This is to ensure a cached rbio will not put its old dbitmap for
the next one whoe uses the cache.
(only for the last patch)
If we have only 8K partial write at the beginning of a full RAID56
stripe, we will write the following contents:
0 8K 32K 64K
Disk 1 (data): |XX| | |
Disk 2 (data): | | |
Disk 3 (parity): |XXXXXXXXXXXXXXX|XXXXXXXXXXXXXXX|
|X| means the sector will be written back to disk.
This is due to the fact that we don't really check if the vertical
stripe has any data (aka, range from higher level bio) for parity
stripes.
The patchset will convert it to the following write pattern:
0 8K 32K 64K
Disk 1 (data): |XX| | |
Disk 2 (data): | | |
Disk 3 (parity): |XX| | |
This is done by fully utilize btrfs_raid_bio::dbitmap which is only
utilized by scrub path.
Now write path (either partial or full write) will also populate
btrfs_raid_bio::dbitmap, and then only assemble sectors marked in
dbitmap for submission.
The first two patches is just to make previous bitmap pointers into
integrated bitmaps inside the bbtrfs_raid_bio and scrub_parity.
This saves 8 bytes for each structure.
The final patch does the most important work, by introducing a new
helper, rbio_add_bio() to mark the btrfs_raid_bio::dbitmap.
Then in finish_rmw() only add sectors which has bit in dbitmap marked to
change the write pattern.
Qu Wenruo (3):
btrfs: use integrated bitmaps for btrfs_raid_bio::dbitmap and
finish_pbitmap
btrfs: use integrated bitmaps for scrub_parity::dbitmap and ebitmap
btrfs: only write the sectors in the vertical stripe which has data
stripes
fs/btrfs/raid56.c | 95 +++++++++++++++++++++++++++++++++++------------
fs/btrfs/scrub.c | 32 +++++++---------
2 files changed, 84 insertions(+), 43 deletions(-)
--
2.36.1
next reply other threads:[~2022-06-01 1:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-01 1:59 Qu Wenruo [this message]
2022-06-01 1:59 ` [PATCH v2 1/3] btrfs: use integrated bitmaps for btrfs_raid_bio::dbitmap and finish_pbitmap Qu Wenruo
2022-06-01 1:59 ` [PATCH v2 2/3] btrfs: use integrated bitmaps for scrub_parity::dbitmap and ebitmap Qu Wenruo
2022-06-01 1:59 ` [PATCH v2 3/3] btrfs: only write the sectors in the vertical stripe which has data stripes Qu Wenruo
2022-06-01 13:12 ` [PATCH v2 0/3] btrfs: raid56: reduce unnecessary parity writes 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.1654048515.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