From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 0/2] btrfs: scrub: reduce memory usage for each scrub_stripe
Date: Mon, 5 May 2025 20:31:02 +0930 [thread overview]
Message-ID: <cover.1746442395.git.wqu@suse.com> (raw)
The first patch fixes a scrub error reporting bug that metadata bytenr
mismatch is reported as csum error, not a metadata error.
The second patch reduces the memory usage of each scrub_stripe by 24
bytes (on systems with 64 bits LONG), this is done by aggregating all
the small bitmaps (at most 16 bits, as we can have at most STRIPE_LEN /
blocksize blocks per stripe) into a larger bitmap.
Just like what we do with subpage helpers.
This will introduce a lot of small helpers:
- Set/clear bitmap range
- Set/clear/test single bit
- Bitmap weight
- Bitmap empty check
- Bitmap read
The last one allows us to read out a unsigned long and use it for
various bitmap operations directly.
In fact the above weight/empty are just a wrapper around the read
helper.
Those helpers are small enough thus can be inlined, this will slightly
increase the overhead but saves 24 bytes per scrub_stripe, and we have
128 scrub_stripes for one device, saving around 3KB for scrub/dev-replace
per device.
Qu Wenruo (2):
btrfs: scrub: fix a wrong error type when metadata bytenr mismatches
btrfs: scrub: aggregate small bitmaps into a larger one
fs/btrfs/scrub.c | 287 ++++++++++++++++++++++++++++++++---------------
1 file changed, 196 insertions(+), 91 deletions(-)
--
2.49.0
next reply other threads:[~2025-05-05 11:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-05 11:01 Qu Wenruo [this message]
2025-05-05 11:01 ` [PATCH 1/2] btrfs: scrub: fix a wrong error type when metadata bytenr mismatches Qu Wenruo
2025-05-05 11:01 ` [PATCH 2/2] btrfs: scrub: aggregate small bitmaps into a larger one Qu Wenruo
2025-05-05 17:42 ` David Sterba
2025-05-05 17:44 ` [PATCH 0/2] btrfs: scrub: reduce memory usage for each scrub_stripe 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.1746442395.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.