btrfs: send: avoid duplicated search for last extent when sending hole

During an incremental send, before determining if we need to send a hole
(write operations full of zeroes) we will search for the last extent's
end offset if we are at the first slot of a leaf and the last processed
extent's end offset is smaller then the current extent's start offset.
However we are repeating this search in case we had the last extent's end
offset undefined (set to the (u64)-1 value) when we entered
maybe_send_hole(), wasting time.

So avoid this duplicated search by combining the two conditions that
trigger a search for the last extent's end offset into a single if
statement.

Reviewed-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>

diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
index dc18d5624ec73ba1dfa0a4219ebef282616b0973..a5da096c64fedcb035ab0de67c17a51785aaec5c 100644 (file)
--- a/fs/btrfs/send.c
+++ b/fs/btrfs/send.c
@@ -6476,21 +6476,18 @@ static int maybe_send_hole(struct send_ctx *sctx, struct btrfs_path *path,
        if (sctx->cur_ino != key->objectid || !need_send_hole(sctx))
                return 0;
 
-       if (sctx->cur_inode_last_extent == (u64)-1) {
-               ret = get_last_extent(sctx, key->offset - 1);
-               if (ret)
-                       return ret;
-       }
-
-       if (path->slots[0] == 0 &&
-           sctx->cur_inode_last_extent < key->offset) {
-               /*
-                * We might have skipped entire leafs that contained only
-                * file extent items for our current inode. These leafs have
-                * a generation number smaller (older) than the one in the
-                * current leaf and the leaf our last extent came from, and
-                * are located between these 2 leafs.
-                */
+       /*
+        * Get last extent's end offset (exclusive) if we haven't determined it
+        * yet (we're processing the first file extent item that is new), or if
+        * we're at the first slot of a leaf and the last extent's end is less
+        * than the current extent's offset, because we might have skipped
+        * entire leaves that contained only file extent items for our current
+        * inode. These leaves have a generation number smaller (older) than the
+        * one in the current leaf and the leaf our last extent came from, and
+        * are located between these 2 leaves.
+        */
+       if ((sctx->cur_inode_last_extent == (u64)-1) ||
+           (path->slots[0] == 0 && sctx->cur_inode_last_extent < key->offset)) {
                ret = get_last_extent(sctx, key->offset - 1);
                if (ret)
                        return ret;