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 0/2] Allow deduplication of the eof block when it is safe to do so
Date: Mon, 16 Dec 2019 18:26:54 +0000	[thread overview]
Message-ID: <20191216182656.15624-1-fdmanana@kernel.org> (raw)

From: Filipe Manana <fdmanana@suse.com>

Hi,

This short series allows deduplication of the last block of a file when
the eof is not aligned to the sector size, as long as the range's end
offset matches the eof of the destination file.

This is a safe case unlike the case where we attempt to clone the block in
the middle of a file (which results in a corruption I found last year and
affected both btrfs and xfs).

This is motivated by btrfs users reporting lower deduplication scores
starting with kernel 5.0, which was the kernel release where btrfs was
changed to use the generic VFS helper generic_remap_file_range_prep().
Users observed that the last block was no longer deduplicated when a
file's size is not block size aligned.  For btrfs this is specially
important because references are kept per extent and not per block, so
not having the last block deduplicated means the entire extent is kept
allocated, making the deduplication not effective and often pointless in
many cases.

Thanks.

Filipe Manana (2):
  fs: allow deduplication of eof block into the end of the destination
    file
  Btrfs: make deduplication with range including the last block work

 fs/btrfs/ioctl.c |  3 ++-
 fs/read_write.c  | 10 ++++------
 2 files changed, 6 insertions(+), 7 deletions(-)

-- 
2.11.0


             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 fdmanana [this message]
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 ` [PATCH 2/2] Btrfs: make deduplication with range including the last block work fdmanana
2019-12-17 15:54   ` 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-1-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).