btrfs: remove constraint on number of visited leaves when replacing extents
authorFilipe Manana <fdmanana@suse.com>
Thu, 3 Feb 2022 14:55:48 +0000 (14:55 +0000)
committerDavid Sterba <dsterba@suse.com>
Mon, 14 Mar 2022 12:13:49 +0000 (13:13 +0100)
At btrfs_drop_extents(), we try to replace a range of file extent items
with a new file extent in a single btree search, to avoid the need to do
a search for deletion, followed by a path release and followed by yet
another search for insertion.

When I originally added that optimization, in commit 1acae57b161ef1
("Btrfs: faster file extent item replace operations"), I left a constraint
to do the fast replace only if we visited a single leaf. That was because
in the most common case we find all file extent items that need to be
deleted (or trimmed) in a single leaf, however it can work for other
common cases like when we need to delete a few file extent items located
at the end of a leaf and a few more located at the beginning of the next
leaf. The key for the new file extent item is greater than the key of
any deleted or trimmed file extent item from previous leaves, so we are
fine to use the last leaf that we found as long as we are holding a
write lock on it - even if the new key ends up at slot 0, as if that's
the case, the btree search has obtained a write lock on any upper nodes
that need to have a key pointer updated.

So removed the constraint that limits the optimization to the case where
we visited only a single leaf.

This change if part of a patchset that is comprised of the following
patches:

  1/6 btrfs: remove unnecessary leaf free space checks when pushing items
  2/6 btrfs: avoid unnecessary COW of leaves when deleting items from a leaf
  3/6 btrfs: avoid unnecessary computation when deleting items from a leaf
  4/6 btrfs: remove constraint on number of visited leaves when replacing extents
  5/6 btrfs: remove useless path release in the fast fsync path
  6/6 btrfs: prepare extents to be logged before locking a log tree path

The last patch in the series has some performance test result in its
changelog.

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
fs/btrfs/file.c

index a0179cc62913ba6c46655e4c5f3d1845c24f24cf..391b05019dbdfa008bb40796e7530207685f702f 100644 (file)
@@ -691,7 +691,6 @@ int btrfs_drop_extents(struct btrfs_trans_handle *trans,
        int modify_tree = -1;
        int update_refs;
        int found = 0;
-       int leafs_visited = 0;
        struct btrfs_path *path = args->path;
 
        args->bytes_found = 0;
@@ -729,7 +728,6 @@ int btrfs_drop_extents(struct btrfs_trans_handle *trans,
                                path->slots[0]--;
                }
                ret = 0;
-               leafs_visited++;
 next_slot:
                leaf = path->nodes[0];
                if (path->slots[0] >= btrfs_header_nritems(leaf)) {
@@ -741,7 +739,6 @@ next_slot:
                                ret = 0;
                                break;
                        }
-                       leafs_visited++;
                        leaf = path->nodes[0];
                        recow = 1;
                }
@@ -987,7 +984,7 @@ delete_extent_item:
         * which case it unlocked our path, so check path->locks[0] matches a
         * write lock.
         */
-       if (!ret && args->replace_extent && leafs_visited == 1 &&
+       if (!ret && args->replace_extent &&
            path->locks[0] == BTRFS_WRITE_LOCK &&
            btrfs_leaf_free_space(leaf) >=
            sizeof(struct btrfs_item) + args->extent_item_size) {