From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 0/5] btrfs: scrub: make scrub uses less memory for metadata scrub
Date: Wed, 2 Mar 2022 16:44:03 +0800 [thread overview]
Message-ID: <cover.1646210051.git.wqu@suse.com> (raw)
Although btrfs scrub works for subpage from day one, it has a small
pitfall:
Scrub will always allocate a full page for each sector.
This causes increased memory usage, although not a big deal, it's still
not ideal.
The patchset will change the behavior by integrating all pages into
scrub_block::pages[], instead of using scrub_sector::page.
Now scrub_sector will no longer hold a page pointer, but uses its
logical bytenr to caculate which page and page range it should use.
This behavior unfortunately still only affects memory usage on metadata
scrub, which uses nodesize for scrub.
For the best case, 64K node size with 64K page size, we waste no memory
to scrub one tree block.
For the worst case, 4K node size with 64K page size, we are no worse
than the existing behavior (still one 64K page for the tree block)
For the default case (16K nodesize), we use one 64K page, compared to
4x64K pages previously.
For data scrubing, we uses sector size, thus it causes no difference.
We need to do more work on data scrubing size to properly handle mutilpe
sectors for non-RAID56 profiles.
The patchset requires the rename patchset.
(https://lore.kernel.org/linux-btrfs/cover.1645530899.git.wqu@suse.com/)
If David is not happy with the big change again, at least first 3
patches can be considered as some cleanup.
Qu Wenruo (5):
btrfs: scrub: use pointer array to replace @sblocks_for_recheck
btrfs: extract the initialization of scrub_block into a helper
function
btrfs: extract the allocation and initialization of scrub_sector into
a helper
btrfs: scrub: introduce scrub_block::pages for more efficient memory
usage for subpage
btrfs: scrub: remove scrub_sector::page and use scrub_block::pages
instead
fs/btrfs/scrub.c | 399 ++++++++++++++++++++++++++++++++---------------
1 file changed, 270 insertions(+), 129 deletions(-)
--
2.35.1
next reply other threads:[~2022-03-02 8:44 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-02 8:44 Qu Wenruo [this message]
2022-03-07 16:36 ` [PATCH 0/5] btrfs: scrub: make scrub uses less memory for metadata scrub David Sterba
2022-03-08 3:49 ` Qu Wenruo
2022-03-14 19:41 ` David Sterba
2022-05-27 15:37 ` 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.1646210051.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.