Received: by 10.213.65.68 with SMTP id h4csp242311imn; Fri, 23 Mar 2018 03:44:18 -0700 (PDT) X-Google-Smtp-Source: AG47ELu8NGnJCaSXNQFV7iaB+tlol5F8QcVMSy58250CyAI8vddDuUxiPI9ll6syXD2D+b8v+R1T X-Received: by 10.99.174.67 with SMTP id e3mr20254110pgp.139.1521801858226; Fri, 23 Mar 2018 03:44:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521801858; cv=none; d=google.com; s=arc-20160816; b=qwcV1dh8Cc/P9tYB1t7W/g2YabNqCX/2LdBffDbbOBnA7jJa3jIhFR9U5ta1hsGc+k pEL+wFpdp1Sc4XUBPIy6F5PGVVbHzrhkBJ29CwrT1Hxsu0s4UCASWOQcG/2y9HEzboxe IsRfEhyzyU0AMAJunJPnR5DVG1aA9r4RS9R+7PdbvbI0puQA6/G4ZefjsPoOsg2SOkkW nVpngyo2FioNVEQ+7dnDN4E3kzOear++xs1/odPc6zIuh5xEyIymEwTQva/qgZJ1T5dH tKu87icEI5c7Y7mabHu91nL/lVkAj+Id1qL7k3VPtausqw+jusVNt8Rtz8eLLVrd298M dFlw== 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=GZUBqjv2rGx1i0YGReOgDu/z4E9F9qQCOQEH583BIbo=; b=pSxNkCqWOayL/QqeqU0JcwxWwM4u91hV5UXlNu9GCH0IShOaIfWJHZCzp4Zd04jIEK koPBp7xQAcO8DUY/KvP+zQUMfcfGE7fbATusAUfBkDGQ+6UlvXacGYtH3DA27paav+HL Osx9X97WkopM8GcrTWPLUbQqBceovWwQ2IysmHA6QNykmUQ0SORMOb8TsErjZyuxc4GH aqDcUwA32gvUQgol9LZ1WqpvkgXa8cQfjXdtZIeFZeSFF8pmDDqz3vZZQnQiMSsrPlKT p2/Bw6EmZG+3kJqVtKWZo2fK7ucWdlXSDh8QU0qkQPDOJDaDbMANmAsfuLzR9Xx67MjV YriA== 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 t81si6524697pfg.273.2018.03.23.03.44.03; Fri, 23 Mar 2018 03:44:18 -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 S933601AbeCWKQL (ORCPT + 99 others); Fri, 23 Mar 2018 06:16:11 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:46604 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933234AbeCWKQG (ORCPT ); Fri, 23 Mar 2018 06:16:06 -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 291FC37; Fri, 23 Mar 2018 10:16:06 +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.4 49/97] Btrfs: send, fix file hole not being preserved due to inline extent Date: Fri, 23 Mar 2018 10:54:36 +0100 Message-Id: <20180323094200.358040036@linuxfoundation.org> X-Mailer: git-send-email 2.16.2 In-Reply-To: <20180323094157.535925724@linuxfoundation.org> References: <20180323094157.535925724@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.4-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 @@ -5008,13 +5008,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); @@ -5028,6 +5034,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. */