From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 0/6] btrfs: preparation patches for the incoming metadata folio conversion
Date: Tue, 11 Jul 2023 15:49:38 +0800 [thread overview]
Message-ID: <cover.1689061099.git.wqu@suse.com> (raw)
[BACKGROUND]
Recently I'm checking on the feasibility on converting metadata handling
to go a folio based solution.
The best part of using a single folio for metadata is, we can get rid of
the complexity of cross-page handling, everything would be just a single
memory operation on a continuous memory range.
[PITFALLS]
One of the biggest problem for metadata folio conversion is, we still
need the current page based solution (or folios with order 0) as a
fallback solution when we can not get a high order folio.
In that case, there would be a hell to handle the four different
combinations (folio/folio, folio/page, page/folio, page/page) for extent
buffer helpers involving two extent buffers.
[OBJECTIVE]
So this patchset is the preparation to reduce direct page operations for
metadata.
The patchset would do this mostly be concentrate the operations to use
the common helper, write_extent_buffer() and read_extent_buffer().
For bitmap operations it's much complex, thus this patchset refactor it
completely to go a 3 part solution:
- Handle the first byte
- Handle the byte aligned ranges
- Handle the last byte
This needs more complex testing (which I failed several times during
development) to prevent regression.
Finally there is only one function which can not be properly migrated,
memmove_extent_buffer(), which has to use memmove() calls, thus must go
per-page mapping handling.
Thankfully if we go folio in the end, the folio based handling would
just be a single memmove(), thus it won't be too much burden.
Qu Wenruo (6):
btrfs: tests: enhance extent buffer bitmap tests
btrfs: refactor extent buffer bitmaps operations
btrfs: use write_extent_buffer() to implement
write_extent_buffer_*id()
btrfs: refactor memcpy_extent_buffer()
btrfs: refactor copy_extent_buffer_full()
btrfs: call copy_extent_buffer_full() inside
btrfs_clone_extent_buffer()
fs/btrfs/extent_io.c | 219 ++++++++++++++-----------------
fs/btrfs/tests/extent-io-tests.c | 161 +++++++++++++++--------
2 files changed, 204 insertions(+), 176 deletions(-)
--
2.41.0
next reply other threads:[~2023-07-11 7:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-11 7:49 Qu Wenruo [this message]
2023-07-11 7:49 ` [PATCH 1/6] btrfs: tests: enhance extent buffer bitmap tests Qu Wenruo
2023-07-11 7:49 ` [PATCH 2/6] btrfs: refactor extent buffer bitmaps operations Qu Wenruo
2023-07-11 7:49 ` [PATCH 3/6] btrfs: use write_extent_buffer() to implement write_extent_buffer_*id() Qu Wenruo
2023-07-11 17:02 ` Sweet Tea Dorminy
2023-07-11 22:43 ` Qu Wenruo
2023-07-11 7:49 ` [PATCH 4/6] btrfs: refactor memcpy_extent_buffer() Qu Wenruo
2023-07-11 7:49 ` [PATCH 5/6] btrfs: refactor copy_extent_buffer_full() Qu Wenruo
2023-07-11 7:49 ` [PATCH 6/6] btrfs: call copy_extent_buffer_full() inside btrfs_clone_extent_buffer() 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.1689061099.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.