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 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


             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 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.