From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH v2 0/4] btrfs: more explaination on extent_map members
Date: Thu, 4 Apr 2024 10:11:57 +1030 [thread overview]
Message-ID: <cover.1712187452.git.wqu@suse.com> (raw)
[REPO]
https://github.com/adam900710/linux.git/ em_cleanup
[CHANGELOG]
v2:
- Add Filipe's cleanup on mod_start/mod_len
These two members are no longer utilized, saving me quite some time on
digging into their usage.
- Update the comments of the extent_map structure
To make them more readable and less confusing.
- Further cleanup for inline extent_map reading
- A new patch to do extra sanity checks for create_io_em()
Firstly pure NOCOW writes should not call create_io_em(), secondly
with the new knowledge of extent_map, it's easier to do extra sanity
checks for the already pretty long parameter list.
Btrfs uses extent_map to represent a in-memory file extent.
There are severam members that are 1:1 mappe in on-disk file extent
items and extent maps:
- extent_map::start == key.offset
- extent_map::len == file_extent_num_bytes
- extent_map::ram_bytes == file_extent_ram_bytes
But that's all, the remaining are pretty different:
- Use block_start to indicate holes/inline extents
Meanwhile btrfs on-disk file extent items go with a dedicated type for
inline extents, and disk_bytenr 0 for holes.
- Extra members for fsync optimization
I'm still not 100% sure how mod_start and mod_len really works though.
- Weird block_start/orig_block_len/orig_start
In theory we can directly go with the same file_extent_disk_bytenr,
file_extent_disk_num_bytes and file_extent_offset to calculate the
remaining members (block_start/orig_start/orig_block_len/block_len).
But for whatever reason, we didn't go that path and have a hell of
weird and inconsistent calculation for them.
I do not have the confidence to handle the mess yet, but as the first
step, I would add comments for those members mostly according to
btrfs_extent_item_to_extent_map(), and hopefully we can improve the
situation in not-far-away future.
Filipe Manana (1):
btrfs: remove not needed mod_start and mod_len from struct extent_map
Qu Wenruo (3):
btrfs: add extra comments on extent_map members
btrfs: simplify the inline extent map creation
btrfs: add extra sanity checks for create_io_em()
fs/btrfs/extent_map.c | 18 -----------
fs/btrfs/extent_map.h | 58 ++++++++++++++++++++++++++++++++----
fs/btrfs/file-item.c | 15 +++++-----
fs/btrfs/inode.c | 44 ++++++++++++++++++++++++---
fs/btrfs/tree-log.c | 4 +--
include/trace/events/btrfs.h | 3 +-
6 files changed, 104 insertions(+), 38 deletions(-)
--
2.44.0
next reply other threads:[~2024-04-03 23:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-03 23:41 Qu Wenruo [this message]
2024-04-03 23:41 ` [PATCH v2 1/4] btrfs: remove not needed mod_start and mod_len from struct extent_map Qu Wenruo
2024-04-04 9:58 ` Filipe Manana
2024-04-04 10:22 ` Qu Wenruo
2024-04-04 10:37 ` Filipe Manana
2024-04-03 23:41 ` [PATCH v2 2/4] btrfs: add extra comments on extent_map members Qu Wenruo
2024-04-04 10:33 ` Filipe Manana
2024-04-04 21:11 ` Qu Wenruo
2024-04-03 23:42 ` [PATCH v2 3/4] btrfs: simplify the inline extent map creation Qu Wenruo
2024-04-04 10:40 ` Filipe Manana
2024-04-03 23:42 ` [PATCH v2 4/4] btrfs: add extra sanity checks for create_io_em() Qu Wenruo
2024-04-04 10: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.1712187452.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.