From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 0/8] btrfs: extent-map: use disk_bytenr/offset to replace block_start/block_len/orig_start
Date: Tue, 9 Apr 2024 08:03:39 +0930 [thread overview]
Message-ID: <cover.1712614770.git.wqu@suse.com> (raw)
[REASON FOR RFC]
Not all sanity checks are implemented, there is a missing check for
ram_bytes on non-compressed extent.
Because even without this series, generic/311 can generate a file extent
with ram_bytes larger than disk_num_bytes.
This seems harmless, but I still want to fix it and implement a full
version of the em sanity check.
[REPO]
https://github.com/adam900710/linux/tree/em_cleanup
Which relies on previous changes on extent maps.
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.
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.
There is another bug related to bad btrfs_file_extent_item::ram_bytes,
which can be larger than disk_num_bytes for non-compressed file extents.
(Generated by generic/311 test case, but it seems to be created on-disk
first)
But so far, the patchset is fine for default fstests run.
The patchset would do two renames as preparation.
Then introduce the new member, the extra sanity checks.
Finally do the migration by remove the old member one-by-one, to make
sure everything is fine.
Qu Wenruo (8):
btrfs: rename extent_map::orig_block_len to disk_num_bytes
btrfs: rename members of can_nocow_file_extent_args
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: reorder disk_bytenr/disk_num_bytes/ram_bytes/offset parameters
fs/btrfs/btrfs_inode.h | 5 +-
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 | 234 ++++++++++++++++--------------
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 | 27 ++--
fs/btrfs/zoned.c | 4 +-
include/trace/events/btrfs.h | 20 +--
15 files changed, 487 insertions(+), 409 deletions(-)
--
2.44.0
next reply other threads:[~2024-04-08 22:34 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-08 22:33 Qu Wenruo [this message]
2024-04-08 22:33 ` [PATCH RFC 1/8] btrfs: rename extent_map::orig_block_len to disk_num_bytes Qu Wenruo
2024-04-09 14:58 ` David Sterba
2024-04-09 21:38 ` Qu Wenruo
2024-04-08 22:33 ` [PATCH RFC 2/8] btrfs: rename members of can_nocow_file_extent_args Qu Wenruo
2024-04-11 14:46 ` Filipe Manana
2024-04-11 22:03 ` Qu Wenruo
2024-04-12 13:21 ` Filipe Manana
2024-04-12 22:00 ` Qu Wenruo
2024-04-12 22:12 ` Qu Wenruo
2024-04-08 22:33 ` [PATCH RFC 3/8] btrfs: introduce new members for extent_map Qu Wenruo
2024-04-11 14:56 ` Filipe Manana
2024-04-11 21:52 ` Qu Wenruo
2024-04-08 22:33 ` [PATCH RFC 4/8] btrfs: introduce extra sanity checks for extent maps Qu Wenruo
2024-04-08 22:33 ` [PATCH RFC 5/8] btrfs: remove extent_map::orig_start member Qu Wenruo
2024-04-09 14:59 ` David Sterba
2024-04-08 22:33 ` [PATCH RFC 6/8] btrfs: remove extent_map::block_len member Qu Wenruo
2024-04-08 22:33 ` [PATCH RFC 7/8] btrfs: remove extent_map::block_start member Qu Wenruo
2024-04-08 22:33 ` [PATCH RFC 8/8] btrfs: reorder disk_bytenr/disk_num_bytes/ram_bytes/offset parameters Qu Wenruo
2024-04-09 14:57 ` [PATCH 0/8] btrfs: extent-map: use disk_bytenr/offset to replace block_start/block_len/orig_start David Sterba
2024-04-09 21:40 ` Qu Wenruo
2024-04-09 22:18 ` 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.1712614770.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.