From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 0/9] btrfs: extent-map: use disk_bytenr/offset to replace block_start/block_len/orig_start
Date: Tue, 30 Apr 2024 07:52:58 +0930 [thread overview]
Message-ID: <cover.1714428940.git.wqu@suse.com> (raw)
[CHANGELOG]
v1:
- Rebased to the latest for-next
To resolve the conflicts with the recently introduced extent map
shrinker
- A new cleanup patch to remove the recursive header inclusion
- Use a new structure to pass the file extent item related members
around
- Add a new comment on why we're intentionally passing incorrect
numbers for NOCOW/PREALLOC ordered extents inside
btrfs_create_dio_extent()
[REPO]
https://github.com/adam900710/linux/tree/em_cleanup
This series introduce two new members (disk_bytenr/offset) to
extent_map, and removes three old members
(block_start/block_len/offset), finally rename one member
(orig_block_len -> disk_num_bytes).
This should save us one u64 for extent_map, although with the recent
extent map shrinker, the saving is not that useful.
But to make things safe to migrate, I introduce extra sanity checks for
extent_map, and do cross check for both old and new members.
The extra sanity checks already exposed one bug (thankfully harmless)
causing em::block_start to be incorrect.
But so far, the patchset is fine for default fstests run.
Furthermore, since we're already having too long parameter lists for
extent_map/ordered_extent/can_nocow_extent, here is a new structure,
btrfs_file_extent, a memory-access-friendly structure to represent a
btrfs_file_extent_item.
With the help of that structure, we can use that to represent a file
extent item without a super long parameter list.
The patchset would do one cleanup first, then rename orig_block_len to
disk_num_bytes.
Then introduce the new member, the extra sanity checks.
Finally introduce the new btrfs_file_extent structure and use that to
remove the older 3 members from extent_map.
Qu Wenruo (9):
btrfs: remove the recursive include of btrfs_inode.h from itself
btrfs: rename extent_map::orig_block_len to disk_num_bytes
btrfs: export the expected file extent through can_nocow_extent()
btrfs: introduce new members for extent_map
btrfs: introduce extra sanity checks for extent maps
btrfs: remove extent_map::orig_start member
btrfs: remove extent_map::block_len member
btrfs: remove extent_map::block_start member
btrfs: remove parameters duplicated from btrfs_file_extent
fs/btrfs/btrfs_inode.h | 6 +-
fs/btrfs/compression.c | 7 +-
fs/btrfs/defrag.c | 14 +-
fs/btrfs/extent_io.c | 10 +-
fs/btrfs/extent_map.c | 187 +++++++++++------
fs/btrfs/extent_map.h | 51 +++--
fs/btrfs/file-item.c | 23 +--
fs/btrfs/file.c | 18 +-
fs/btrfs/inode.c | 333 +++++++++++++++---------------
fs/btrfs/ordered-data.c | 20 +-
fs/btrfs/ordered-data.h | 22 +-
fs/btrfs/relocation.c | 5 +-
fs/btrfs/tests/extent-map-tests.c | 114 +++++-----
fs/btrfs/tests/inode-tests.c | 177 ++++++++--------
fs/btrfs/tree-log.c | 25 ++-
fs/btrfs/zoned.c | 4 +-
include/trace/events/btrfs.h | 26 +--
17 files changed, 560 insertions(+), 482 deletions(-)
--
2.44.0
next reply other threads:[~2024-04-29 22:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-29 22:22 Qu Wenruo [this message]
2024-04-29 22:22 ` [PATCH 1/9] btrfs: remove the recursive include of btrfs_inode.h from itself Qu Wenruo
2024-04-29 22:23 ` [PATCH 2/9] btrfs: rename extent_map::orig_block_len to disk_num_bytes Qu Wenruo
2024-04-29 22:23 ` [PATCH 3/9] btrfs: export the expected file extent through can_nocow_extent() Qu Wenruo
2024-04-29 22:23 ` [PATCH 4/9] btrfs: introduce new members for extent_map Qu Wenruo
2024-04-29 22:23 ` [PATCH 5/9] btrfs: introduce extra sanity checks for extent maps Qu Wenruo
2024-04-29 22:23 ` [PATCH 6/9] btrfs: remove extent_map::orig_start member Qu Wenruo
2024-04-29 22:23 ` [PATCH 7/9] btrfs: remove extent_map::block_len member Qu Wenruo
2024-04-29 22:23 ` [PATCH 8/9] btrfs: remove extent_map::block_start member Qu Wenruo
2024-04-29 22:23 ` [PATCH 9/9] btrfs: remove parameters duplicated from btrfs_file_extent 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.1714428940.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.