linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: fdmanana@kernel.org
To: linux-fsdevel@vger.kernel.org
Cc: linux-btrfs@vger.kernel.org, linux-xfs@vger.kernel.org,
	darrick.wong@oracle.com, Filipe Manana <fdmanana@suse.com>
Subject: [PATCH 2/2] Btrfs: make deduplication with range including the last block work
Date: Mon, 16 Dec 2019 18:26:56 +0000	[thread overview]
Message-ID: <20191216182656.15624-3-fdmanana@kernel.org> (raw)
In-Reply-To: <20191216182656.15624-1-fdmanana@kernel.org>

From: Filipe Manana <fdmanana@suse.com>

Since btrfs was migrated to use the generic VFS helpers for clone and
deduplication, it stopped allowing for the last block of a file to be
deduplicated when the source file size is not sector size aligned (when
eof is somewhere in the middle of the last block). There are two reasons
for that:

1) The generic code always rounds down, to a multiple of the block size,
   the range's length for deduplications. This means we end up never
   deduplicating the last block when the eof is not block size aligned,
   even for the safe case where the destination range's end offset matches
   the destination file's size. That rounding down operation is done at
   generic_remap_check_len();

2) Because of that, the btrfs specific code does not expect anymore any
   non-aligned range length's for deduplication and therefore does not
   work if such nona-aligned length is given.

This patch addresses that second part, and it depends on a patch that
fixes generic_remap_check_len(), in the VFS, which was submitted ealier
and has the following subject:

  "fs: allow deduplication of eof block into the end of the destination file"

These two patches address reports from users that started seeing lower
deduplication rates due to the last block never being deduplicated when
the file size is not aligned to the filesystem's block size.

Link: https://lore.kernel.org/linux-btrfs/2019-1576167349.500456@svIo.N5dq.dFFD/
Signed-off-by: Filipe Manana <fdmanana@suse.com>
---
 fs/btrfs/ioctl.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 3418decb9e61..c41c276ff272 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -3237,6 +3237,7 @@ static void btrfs_double_extent_lock(struct inode *inode1, u64 loff1,
 static int btrfs_extent_same_range(struct inode *src, u64 loff, u64 len,
 				   struct inode *dst, u64 dst_loff)
 {
+	const u64 bs = BTRFS_I(src)->root->fs_info->sb->s_blocksize;
 	int ret;
 
 	/*
@@ -3244,7 +3245,7 @@ static int btrfs_extent_same_range(struct inode *src, u64 loff, u64 len,
 	 * source range to serialize with relocation.
 	 */
 	btrfs_double_extent_lock(src, loff, dst, dst_loff, len);
-	ret = btrfs_clone(src, dst, loff, len, len, dst_loff, 1);
+	ret = btrfs_clone(src, dst, loff, len, ALIGN(len, bs), dst_loff, 1);
 	btrfs_double_extent_unlock(src, loff, dst, dst_loff, len);
 
 	return ret;
-- 
2.11.0


  parent reply	other threads:[~2019-12-16 18:27 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-16 18:26 [PATCH 0/2] Allow deduplication of the eof block when it is safe to do so fdmanana
2019-12-16 18:26 ` [PATCH 1/2] fs: allow deduplication of eof block into the end of the destination file fdmanana
2019-12-17 15:52   ` Josef Bacik
2020-01-07 16:23   ` Filipe Manana
2020-01-07 17:57     ` Darrick J. Wong
2020-01-08 11:36       ` Filipe Manana
2020-01-08 16:15         ` Darrick J. Wong
2020-01-09 19:00           ` Filipe Manana
2020-01-09 19:12             ` Darrick J. Wong
2020-01-14 14:36               ` Filipe Manana
2020-01-22  0:35                 ` Darrick J. Wong
2020-01-22 12:38                   ` David Sterba
2019-12-16 18:26 ` fdmanana [this message]
2019-12-17 15:54   ` [PATCH 2/2] Btrfs: make deduplication with range including the last block work Josef Bacik
2019-12-29  5:22   ` Zygo Blaxell
2020-01-07 16:18     ` Filipe Manana
2020-01-07 18:16       ` Zygo Blaxell
2020-01-08 11:42         ` Filipe Manana
2020-01-08 14:53           ` David Sterba
2020-01-23 17:37 ` [PATCH 0/2] Allow deduplication of the eof block when it is safe to do so David Sterba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191216182656.15624-3-fdmanana@kernel.org \
    --to=fdmanana@kernel.org \
    --cc=darrick.wong@oracle.com \
    --cc=fdmanana@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).