Received: by 10.213.65.68 with SMTP id h4csp270326imn; Fri, 23 Mar 2018 04:23:40 -0700 (PDT) X-Google-Smtp-Source: AG47ELvfYODY4m8LyWCV8DYwJ30WrVXSVIlinVeoM5gm1LrSF9/P8mOEA4layfEJQ4LHilVBnzEk X-Received: by 2002:a17:902:a516:: with SMTP id s22-v6mr28456799plq.191.1521804220912; Fri, 23 Mar 2018 04:23:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521804220; cv=none; d=google.com; s=arc-20160816; b=yGrX8LgAIJoLni11W90yUQT4E9RKOCYhwovbm+cuU0mvCdSKD4rsPXYB5BHPbxKMKq Q+kauf6fsSbiA+hfHEhyVd5dU00/mjVBMddWiRP7e8tXXLO993sF1qNrhhCbpygzrJWy 4rEsgqVdOap6iJ01lkT1lxw9aLpAeXcRE/n4rpqeNc4iAbxfCF9nmbGg4XBVTKIf54Y7 JKSLNTsi2QFGi2rHVyfmbTwyoy3h+SxotNQxGaYZSbO08+2MNlrAdvYnBe9Sf51lypqZ biEClEI/hQBa2Z3lqNCYM1FyIOGXu7xTyaQBjZK1gCiCRACp6Z1VTUCjv0uwg8G6bUHe zcvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=kdI0BQu38fxa4oO9yGPTzr5eU07cla9PszG5pe2L6Fk=; b=U3htko/v/3zKb1EqsQITM66ai85KWwA0vUlYQZp6qg70LFWPiPXCBzcvBss59C4hHs iNlKs9jy//aqhD6L+YqKGqmtf/eQ6gUBLR3tLbmEdAE/YrnQ4ncSStGvCadoPDeCCjIg nWg23qRx/N8qiU+05LDGE/pVvTZvfUQDQNk7gnoXKdw1w03tTFKqeZqltITXZbek/wwH KfP6GtyjciIYYVLXv33NVw5Wpe4LyE5dfOC0sJ5AelpGVuakqvwSP+j9kO9EjiO4DmDE d/LAHmX9iWQMuPAuwW6lWa9GUcRQYiMMAwgsQ00RJOAuujr4gMTs/LT8W6mFiw7xH4PP j9dw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 38-v6si8417564pld.47.2018.03.23.04.23.26; Fri, 23 Mar 2018 04:23:40 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752349AbeCWLWe (ORCPT + 99 others); Fri, 23 Mar 2018 07:22:34 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:41576 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755474AbeCWKIK (ORCPT ); Fri, 23 Mar 2018 06:08:10 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id DE345DF6; Fri, 23 Mar 2018 10:08:09 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Filipe Manana , Liu Bo , Sasha Levin Subject: [PATCH 4.9 077/177] Btrfs: send, fix file hole not being preserved due to inline extent Date: Fri, 23 Mar 2018 10:53:25 +0100 Message-Id: <20180323094208.708796451@linuxfoundation.org> X-Mailer: git-send-email 2.16.2 In-Reply-To: <20180323094205.090519271@linuxfoundation.org> References: <20180323094205.090519271@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.9-stable review patch. If anyone has any objections, please let me know. ------------------ From: Filipe Manana [ Upstream commit e1cbfd7bf6dabdac561c75d08357571f44040a45 ] Normally we don't have inline extents followed by regular extents, but there's currently at least one harmless case where this happens. For example, when the page size is 4Kb and compression is enabled: $ mkfs.btrfs -f /dev/sdb $ mount -o compress /dev/sdb /mnt $ xfs_io -f -c "pwrite -S 0xaa 0 4K" -c "fsync" /mnt/foobar $ xfs_io -c "pwrite -S 0xbb 8K 4K" -c "fsync" /mnt/foobar In this case we get a compressed inline extent, representing 4Kb of data, followed by a hole extent and then a regular data extent. The inline extent was not expanded/converted to a regular extent exactly because it represents 4Kb of data. This does not cause any apparent problem (such as the issue solved by commit e1699d2d7bf6 ("btrfs: add missing memset while reading compressed inline extents")) except trigger an unexpected case in the incremental send code path that makes us issue an operation to write a hole when it's not needed, resulting in more writes at the receiver and wasting space at the receiver. So teach the incremental send code to deal with this particular case. The issue can be currently triggered by running fstests btrfs/137 with compression enabled (MOUNT_OPTIONS="-o compress" ./check btrfs/137). Signed-off-by: Filipe Manana Reviewed-by: Liu Bo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/send.c | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) --- a/fs/btrfs/send.c +++ b/fs/btrfs/send.c @@ -5156,13 +5156,19 @@ static int is_extent_unchanged(struct se while (key.offset < ekey->offset + left_len) { ei = btrfs_item_ptr(eb, slot, struct btrfs_file_extent_item); right_type = btrfs_file_extent_type(eb, ei); - if (right_type != BTRFS_FILE_EXTENT_REG) { + if (right_type != BTRFS_FILE_EXTENT_REG && + right_type != BTRFS_FILE_EXTENT_INLINE) { ret = 0; goto out; } right_disknr = btrfs_file_extent_disk_bytenr(eb, ei); - right_len = btrfs_file_extent_num_bytes(eb, ei); + if (right_type == BTRFS_FILE_EXTENT_INLINE) { + right_len = btrfs_file_extent_inline_len(eb, slot, ei); + right_len = PAGE_ALIGN(right_len); + } else { + right_len = btrfs_file_extent_num_bytes(eb, ei); + } right_offset = btrfs_file_extent_offset(eb, ei); right_gen = btrfs_file_extent_generation(eb, ei); @@ -5176,6 +5182,19 @@ static int is_extent_unchanged(struct se goto out; } + /* + * We just wanted to see if when we have an inline extent, what + * follows it is a regular extent (wanted to check the above + * condition for inline extents too). This should normally not + * happen but it's possible for example when we have an inline + * compressed extent representing data with a size matching + * the page size (currently the same as sector size). + */ + if (right_type == BTRFS_FILE_EXTENT_INLINE) { + ret = 0; + goto out; + } + left_offset_fixed = left_offset; if (key.offset < ekey->offset) { /* Fix the right offset for 2a and 7. */