From patchwork Sat May 31 01:31:05 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Filipe Manana X-Patchwork-Id: 4274601 Return-Path: X-Original-To: patchwork-linux-btrfs@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id D24CDBEEA7 for ; Sat, 31 May 2014 00:31:18 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 12B7C201C0 for ; Sat, 31 May 2014 00:31:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1F35A201BC for ; Sat, 31 May 2014 00:31:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030213AbaEaAbO (ORCPT ); Fri, 30 May 2014 20:31:14 -0400 Received: from mail-wg0-f43.google.com ([74.125.82.43]:62363 "EHLO mail-wg0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030195AbaEaAbN (ORCPT ); Fri, 30 May 2014 20:31:13 -0400 Received: by mail-wg0-f43.google.com with SMTP id l18so2677575wgh.2 for ; Fri, 30 May 2014 17:31:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=GlLOQsMTIm2fF1L6b+8V+kWyrUHSiZXeFxo7LYJod7o=; b=mKkR5QxaSANivu8eyApWJtej5K+6LtaM7eUblKYXwRROTkunNvaG1oQFtHG701DPuR kUV4+YzABkCPVT5JQDSXXgf1RFpvR2Ek9XUSgA0kaVn8biuvNVp2du9YD1ioF/AqTjvS +Xh+wGOK7nAj1eaMG7yTXvSJVotItbBfnSppiRb2aadaSGk8A2xViHmsOWEWGPaoJO9U zuSbbWKPccY1HjwIbywg17suyqPBVA1phAAsAC3NLwTWCAWFjUb2ZAleOOBdCuo1ZcLe Zf2zLWt0u8rICMvE/UjeXoxMdOH+qmrImxq0PshxveO4dQiKA+FjE7M88FD5N2lDUQiU sPPw== X-Received: by 10.180.74.114 with SMTP id s18mr1242370wiv.37.1401496271912; Fri, 30 May 2014 17:31:11 -0700 (PDT) Received: from debian-vm3.lan (bl13-158-17.dsl.telepac.pt. [85.246.158.17]) by mx.google.com with ESMTPSA id y20sm10103230wiv.14.2014.05.30.17.31.10 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 30 May 2014 17:31:11 -0700 (PDT) From: Filipe David Borba Manana To: linux-btrfs@vger.kernel.org Cc: Filipe David Borba Manana Subject: [PATCH v3] Btrfs: avoid visiting all extent items when cloning a range Date: Sat, 31 May 2014 02:31:05 +0100 Message-Id: <1401499865-11669-1-git-send-email-fdmanana@gmail.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1401469001-26866-1-git-send-email-fdmanana@gmail.com> References: <1401469001-26866-1-git-send-email-fdmanana@gmail.com> Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP When cloning a range of a file, we were visiting all the extent items in the btree that belong to our source inode. We don't need to visit those extent items that don't overlap the range we are cloning, as doing so only makes us waste time and do unnecessary btree navigations (btrfs_next_leaf) for inodes that have a large number of file extent items in the btree. Signed-off-by: Filipe David Borba Manana --- V2: Leave the loop as soon as we process the last extent, to avoid one extra and unnecessary btree search. V3: Removed unintentional and unrelated change from v2. fs/btrfs/ioctl.c | 26 ++++++++++++++++++++++---- 1 file changed, 22 insertions(+), 4 deletions(-) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index 603c036..04ece8f 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -3025,7 +3025,7 @@ static int btrfs_clone(struct inode *src, struct inode *inode, /* clone data */ key.objectid = btrfs_ino(src); key.type = BTRFS_EXTENT_DATA_KEY; - key.offset = 0; + key.offset = off; while (1) { /* @@ -3037,6 +3037,17 @@ static int btrfs_clone(struct inode *src, struct inode *inode, 0, 0); if (ret < 0) goto out; + /* + * First search, if no extent item that starts at offset off was + * found but the previous item is an extent item, it's possible + * it might overlap our target range, therefore process it. + */ + if (key.offset == off && ret > 0 && path->slots[0] > 0) { + btrfs_item_key_to_cpu(path->nodes[0], &key, + path->slots[0] - 1); + if (key.type == BTRFS_EXTENT_DATA_KEY) + path->slots[0]--; + } nritems = btrfs_header_nritems(path->nodes[0]); process_slot: @@ -3086,10 +3097,16 @@ process_slot: extent); } - if (key.offset + datal <= off || - key.offset >= off + len - 1) { + /* + * The first search might have left us at an extent + * item that ends before our target range's start, can + * happen if we have holes and NO_HOLES feature enabled. + */ + if (key.offset + datal <= off) { path->slots[0]++; goto process_slot; + } else if (key.offset >= off + len) { + break; } size = btrfs_item_size_nr(leaf, slot); @@ -3296,6 +3313,8 @@ process_slot: goto out; } ret = btrfs_end_transaction(trans, root); + if (new_key.offset + datal >= destoff + len) + break; } btrfs_release_path(path); key.offset++; @@ -3303,7 +3322,6 @@ process_slot: ret = 0; out: - btrfs_release_path(path); btrfs_free_path(path); vfree(buf); return ret;