Received: by 10.213.65.68 with SMTP id h4csp232233imn; Fri, 23 Mar 2018 03:29:42 -0700 (PDT) X-Google-Smtp-Source: AG47ELul3PrWsLLbloCrO/rnElPZvHC5j+Hd3MoxWTbCAblqiyZ1yl0Lz8M4l3odjqkzysT75afn X-Received: by 10.167.129.217 with SMTP id c25mr3978835pfn.143.1521800981999; Fri, 23 Mar 2018 03:29:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521800981; cv=none; d=google.com; s=arc-20160816; b=K/ejvljgFUjqJVaMfegzv0uvJPcD2wqoOft3GNwJQfLw2LcsmDVUORn9Ee059RV28F cDY1MA7o5exWjIVdDD1/IDg60uBapPT4x0LZNcKm04W28eeT+7YmBI51Fa9jkgvaXeb5 UuNxhSOYQj48xayhO4DdT9PUgSTUe3acx+mZTHCDeTjdEFLr8LCLmUW33VyLSJZiEiqu 48dPkl0aiCGAk3awqrN96KZLEUo2uCELu3KIXIiUD17+HXxA6FsDRfKOwJijpRL32AFY +f8LSXUL6qlbpbQPfI123orhNYIRymlOOaqgetJ7gnFqCji5bPhw1SnZXe4nzkGDJUnX 2DXQ== 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=eMVoRQbY+pT/rMwYV5SiywF2rE/Rud3Q7/PRiysEPjY=; b=idqo+eNZ0O7FRoh6Rq0/rXozIV2xNELx7M7qo2JC9oUn6czZTXoV8t4ySyzboG2g09 YdB8WhH9HY6esR48QbAo/8s7WJ8wvxZkAW3lRG+MP9XtnmjAFBLEmGVxcBWB5JbJ2jLY ulhVNTRtZ8B+B0rn2NBEzlkhBtc3DpFVMxrrQz1Fsee1d5OQnHzmd238BSsILkSc8pvD p4V8yt8+yKs/v0A08bG/NVAw/D0NOaPRY6KLajpnr/dFMNK7DEfiV9W4CC7IQKYMSF0+ gQ1h/Godcz2jVhSKNlHPyqq8BQnLdt1RYffk5t5NSR86eMtm8TfG+zyCTmuA/V9DJrjB 1OGA== 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 p12-v6si7900276plk.295.2018.03.23.03.29.27; Fri, 23 Mar 2018 03:29:41 -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 S1756114AbeCWK21 (ORCPT + 99 others); Fri, 23 Mar 2018 06:28:27 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:48050 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933971AbeCWKTT (ORCPT ); Fri, 23 Mar 2018 06:19:19 -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 2416AF7C; Fri, 23 Mar 2018 10:19:18 +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 3.18 25/47] Btrfs: send, fix file hole not being preserved due to inline extent Date: Fri, 23 Mar 2018 10:55:16 +0100 Message-Id: <20180323094249.194276396@linuxfoundation.org> X-Mailer: git-send-email 2.16.2 In-Reply-To: <20180323094248.117679641@linuxfoundation.org> References: <20180323094248.117679641@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 3.18-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 @@ -4663,13 +4663,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); @@ -4683,6 +4689,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. */