Skip to content

Commit 0e9e135

Browse files
fdmananakdave
authored andcommitted
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>
1 parent 0478adf commit 0e9e135

1 file changed

Lines changed: 12 additions & 15 deletions

File tree

fs/btrfs/send.c

Lines changed: 12 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -6476,21 +6476,18 @@ static int maybe_send_hole(struct send_ctx *sctx, struct btrfs_path *path,
64766476
if (sctx->cur_ino != key->objectid || !need_send_hole(sctx))
64776477
return 0;
64786478

6479-
if (sctx->cur_inode_last_extent == (u64)-1) {
6480-
ret = get_last_extent(sctx, key->offset - 1);
6481-
if (ret)
6482-
return ret;
6483-
}
6484-
6485-
if (path->slots[0] == 0 &&
6486-
sctx->cur_inode_last_extent < key->offset) {
6487-
/*
6488-
* We might have skipped entire leafs that contained only
6489-
* file extent items for our current inode. These leafs have
6490-
* a generation number smaller (older) than the one in the
6491-
* current leaf and the leaf our last extent came from, and
6492-
* are located between these 2 leafs.
6493-
*/
6479+
/*
6480+
* Get last extent's end offset (exclusive) if we haven't determined it
6481+
* yet (we're processing the first file extent item that is new), or if
6482+
* we're at the first slot of a leaf and the last extent's end is less
6483+
* than the current extent's offset, because we might have skipped
6484+
* entire leaves that contained only file extent items for our current
6485+
* inode. These leaves have a generation number smaller (older) than the
6486+
* one in the current leaf and the leaf our last extent came from, and
6487+
* are located between these 2 leaves.
6488+
*/
6489+
if ((sctx->cur_inode_last_extent == (u64)-1) ||
6490+
(path->slots[0] == 0 && sctx->cur_inode_last_extent < key->offset)) {
64946491
ret = get_last_extent(sctx, key->offset - 1);
64956492
if (ret)
64966493
return ret;

0 commit comments

Comments
 (0)