All of lore.kernel.org
 help / color / mirror / Atom feed
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


             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.