From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH v2 00/11] btrfs: extent-map: unify the members with btrfs_ordered_extent
Date: Fri, 3 May 2024 15:31:35 +0930 [thread overview]
Message-ID: <cover.1714707707.git.wqu@suse.com> (raw)
[CHANGELOG]
v2:
- Rebased to the latest for-next
There is a conflicts with extent locking, and maybe some other
hidden conflicts for NOCOW/PREALLOC?
As previously the patchset passes fstests auto group, but after
the merging with other patches, it always crashes as btrfs/060.
- Fix an error in the final cleanup patch
It's the NOCOW/PREALLOC shenanigans again, in the buffered NOCOW path,
that we have to use the old inaccurate numbers for NOCOW/PREALLOC OEs.
- Split the final cleanup into 4 patches
Most cleanups are very straightforward, but the cleanup for
btrfs_alloc_ordered_extent() needs extra special handling for
NOCOW/PREALLOC.
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 rename orig_block_len to disk_num_bytes first.
Then introduce the new member, the extra sanity checks, and introduce the
new btrfs_file_extent structure and use that to remove the older 3 members
from extent_map.
After all above works done, use btrfs_file_extent to further cleanup
can_nocow_file_extent_args()/btrfs_alloc_ordered_extent()/create_io_em()/
btrfs_create_dio_extent().
The cleanup is in fact pretty tricky, the current code base never
expects correct numbers for NOCOW/PREALLOC OEs, thus we have to keep the
old but incorrect numbers just for NOCOW/PREALLOC.
I will address the NOCOW/PREALLOC shenanigans the future, but
after the huge cleanup across multiple core structures.
Qu Wenruo (11):
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: cleanup duplicated parameters related to
can_nocow_file_extent_args
btrfs: cleanup duplicated parameters related to
btrfs_alloc_ordered_extent
btrfs: cleanup duplicated parameters related to create_io_em()
btrfs: cleanup duplicated parameters related to
btrfs_create_dio_extent()
fs/btrfs/btrfs_inode.h | 4 +-
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 | 308 +++++++++++++-----------------
fs/btrfs/ordered-data.c | 36 +++-
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, 548 insertions(+), 483 deletions(-)
--
2.45.0
next reply other threads:[~2024-05-03 6:02 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-03 6:01 Qu Wenruo [this message]
2024-05-03 6:01 ` [PATCH v2 01/11] btrfs: rename extent_map::orig_block_len to disk_num_bytes Qu Wenruo
2024-05-09 16:15 ` Filipe Manana
2024-05-03 6:01 ` [PATCH v2 02/11] btrfs: export the expected file extent through can_nocow_extent() Qu Wenruo
2024-05-09 16:22 ` Filipe Manana
2024-05-09 21:55 ` Qu Wenruo
2024-05-03 6:01 ` [PATCH v2 03/11] btrfs: introduce new members for extent_map Qu Wenruo
2024-05-09 17:05 ` Filipe Manana
2024-05-09 22:11 ` Qu Wenruo
2024-05-10 11:26 ` Filipe Manana
2024-05-10 22:26 ` Qu Wenruo
2024-05-13 12:48 ` Filipe Manana
2024-05-13 12:54 ` Filipe Manana
2024-05-13 17:31 ` Filipe Manana
2024-05-03 6:01 ` [PATCH v2 04/11] btrfs: introduce extra sanity checks for extent maps Qu Wenruo
2024-05-13 12:21 ` Filipe Manana
2024-05-13 22:34 ` Qu Wenruo
2024-05-03 6:01 ` [PATCH v2 05/11] btrfs: remove extent_map::orig_start member Qu Wenruo
2024-05-13 13:09 ` Filipe Manana
2024-05-13 22:14 ` Qu Wenruo
2024-05-03 6:01 ` [PATCH v2 06/11] btrfs: remove extent_map::block_len member Qu Wenruo
2024-05-13 17:44 ` Filipe Manana
2024-05-14 7:09 ` Qu Wenruo
2024-05-03 6:01 ` [PATCH v2 07/11] btrfs: remove extent_map::block_start member Qu Wenruo
2024-05-16 17:28 ` Filipe Manana
2024-05-16 22:45 ` Qu Wenruo
2024-05-03 6:01 ` [PATCH v2 08/11] btrfs: cleanup duplicated parameters related to can_nocow_file_extent_args Qu Wenruo
2024-05-20 15:55 ` Filipe Manana
2024-05-20 22:13 ` Qu Wenruo
2024-05-03 6:01 ` [PATCH v2 09/11] btrfs: cleanup duplicated parameters related to btrfs_alloc_ordered_extent Qu Wenruo
2024-05-20 16:31 ` Filipe Manana
2024-05-03 6:01 ` [PATCH v2 10/11] btrfs: cleanup duplicated parameters related to create_io_em() Qu Wenruo
2024-05-20 16:46 ` Filipe Manana
2024-05-03 6:01 ` [PATCH v2 11/11] btrfs: cleanup duplicated parameters related to btrfs_create_dio_extent() Qu Wenruo
2024-05-20 16:48 ` Filipe Manana
2024-05-23 4:03 ` Qu Wenruo
2024-05-03 11:53 ` [PATCH v2 00/11] btrfs: extent-map: unify the members with btrfs_ordered_extent David Sterba
2024-05-20 16:55 ` Filipe Manana
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.1714707707.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).