public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: fdmanana@kernel.org
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 00/13] btrfs: fixes and cleanups around extent maps
Date: Mon, 19 Sep 2022 15:06:27 +0100	[thread overview]
Message-ID: <cover.1663594828.git.fdmanana@suse.com> (raw)

From: Filipe Manana <fdmanana@suse.com>

The following patchset fixes a bug related to dropping extent maps that
can make an fsync miss a new extent, does several cleanups and some
small performance improvements when dropping and searching for extent
maps as well as when flushing delalloc in COW mode. These came out while
working on some upcoming changes for fiemap, but since they are really
independent, I'm sending them as a separate patchset.
The last patch in the series has a test and results in its changelog.

Filipe Manana (13):
  btrfs: fix missed extent on fsync after dropping extent maps
  btrfs: move btrfs_drop_extent_cache() to extent_map.c
  btrfs: use extent_map_end() at btrfs_drop_extent_map_range()
  btrfs: use cond_resched_rwlock_write() during inode eviction
  btrfs: move open coded extent map tree deletion out of inode eviction
  btrfs: add helper to replace extent map range with a new extent map
  btrfs: remove the refcount warning/check at free_extent_map()
  btrfs: remove unnecessary extent map initializations
  btrfs: assert tree is locked when clearing extent map from logging
  btrfs: remove unnecessary NULL pointer checks when searching extent maps
  btrfs: remove unnecessary next extent map search
  btrfs: avoid pointless extent map tree search when flushing delalloc
  btrfs: drop extent map range more efficiently

 fs/btrfs/ctree.h             |   2 -
 fs/btrfs/extent_map.c        | 343 ++++++++++++++++++++++++++++++++---
 fs/btrfs/extent_map.h        |   8 +
 fs/btrfs/file.c              | 184 ++-----------------
 fs/btrfs/free-space-cache.c  |   2 +-
 fs/btrfs/inode.c             | 101 +++--------
 fs/btrfs/relocation.c        |  20 +-
 fs/btrfs/tests/inode-tests.c |   2 +-
 8 files changed, 373 insertions(+), 289 deletions(-)

-- 
2.35.1


             reply	other threads:[~2022-09-19 14:06 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-19 14:06 fdmanana [this message]
2022-09-19 14:06 ` [PATCH 01/13] btrfs: fix missed extent on fsync after dropping extent maps fdmanana
2022-09-20 10:19   ` Anand Jain
2022-09-20 10:27     ` Filipe Manana
2022-09-21 11:11       ` Anand Jain
2022-09-21 11:11   ` Anand Jain
2022-09-19 14:06 ` [PATCH 02/13] btrfs: move btrfs_drop_extent_cache() to extent_map.c fdmanana
2022-09-19 14:06 ` [PATCH 03/13] btrfs: use extent_map_end() at btrfs_drop_extent_map_range() fdmanana
2022-09-19 14:06 ` [PATCH 04/13] btrfs: use cond_resched_rwlock_write() during inode eviction fdmanana
2022-09-19 14:06 ` [PATCH 05/13] btrfs: move open coded extent map tree deletion out of " fdmanana
2022-09-19 14:06 ` [PATCH 06/13] btrfs: add helper to replace extent map range with a new extent map fdmanana
2022-09-19 14:06 ` [PATCH 07/13] btrfs: remove the refcount warning/check at free_extent_map() fdmanana
2022-09-19 14:06 ` [PATCH 08/13] btrfs: remove unnecessary extent map initializations fdmanana
2022-09-19 14:06 ` [PATCH 09/13] btrfs: assert tree is locked when clearing extent map from logging fdmanana
2022-09-19 14:06 ` [PATCH 10/13] btrfs: remove unnecessary NULL pointer checks when searching extent maps fdmanana
2022-09-22 16:04   ` David Sterba
2022-09-19 14:06 ` [PATCH 11/13] btrfs: remove unnecessary next extent map search fdmanana
2022-09-19 14:06 ` [PATCH 12/13] btrfs: avoid pointless extent map tree search when flushing delalloc fdmanana
2022-09-19 14:06 ` [PATCH 13/13] btrfs: drop extent map range more efficiently fdmanana
2022-09-22 16:25 ` [PATCH 00/13] btrfs: fixes and cleanups around extent maps 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.1663594828.git.fdmanana@suse.com \
    --to=fdmanana@kernel.org \
    --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