From: Omar Sandoval <osandov@osandov.com>
To: linux-btrfs@vger.kernel.org, linux-xfs@vger.kernel.org
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>,
Qu Wenruo <quwenruo@cn.fujitsu.com>,
Christoph Hellwig <hch@infradead.org>,
kernel-team@fb.com
Subject: [RFC PATCH 0/2] Btrfs: make a source length of 0 imply EOF for dedupe
Date: Thu, 17 Nov 2016 16:07:48 -0800 [thread overview]
Message-ID: <cover.1479427384.git.osandov@fb.com> (raw)
From: Omar Sandoval <osandov@fb.com>
This is the follow-up to the discussions here [1] and here [2] that
makes Btrfs treat a src_length of 0 to dedupe as "until EOF". The
implementation is straightforward, but there are a few catches that
convinced me to post this as an RFC:
1. We still don't know for sure whether userspace cares about the
original Btrfs behavior. Darrick and I both seem to think not, but
hopefully someone will speak up if it matters to them.
2. When doing the implicit EOF, XFS returns 0 for bytes_deduped. I
copied this in my implementation, but I'm guessing that's a bug
rather than a feature.
3. Both XFS and Btrfs cap each dedupe operation to 16MB, but the
implicit EOF gets around this in the existing XFS implementation. I
copied this for the Btrfs implementation.
So now we have 3 options:
a) Apply these patches as-is.
b) Fix XFS to both return the actual bytes_deduped and cap the length
for the EOF case. Do the same for Btrfs.
c) Make XFS consistent with the existing Btrfs behavior.
I'm starting to lean towards option c after writing this cover letter,
but I might as well send these out and get a second opinion.
Thanks!
1: http://marc.info/?l=linux-btrfs&m=146828374631829&w=2
2: http://marc.info/?l=linux-btrfs&m=147694962912532&w=2
Omar Sandoval (2):
Btrfs: refactor btrfs_extent_same() slightly
Btrfs: make a source length of 0 imply EOF for dedupe
fs/btrfs/ioctl.c | 45 ++++++++++++++++++++-------------------------
1 file changed, 20 insertions(+), 25 deletions(-)
--
2.10.2
next reply other threads:[~2016-11-18 0:08 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-18 0:07 Omar Sandoval [this message]
2016-11-18 0:07 ` [RFC PATCH 1/2] Btrfs: refactor btrfs_extent_same() slightly Omar Sandoval
2016-11-18 3:22 ` Qu Wenruo
2016-11-18 3:22 ` Qu Wenruo
2016-11-18 0:07 ` [RFC PATCH 2/2] Btrfs: make a source length of 0 imply EOF for dedupe Omar Sandoval
2016-11-18 5:38 ` [RFC PATCH 0/2] " Christoph Hellwig
2016-11-22 21:17 ` Darrick J. Wong
2016-11-23 2:02 ` Zygo Blaxell
2016-11-23 2:44 ` Darrick J. Wong
2016-11-24 5:16 ` Zygo Blaxell
2016-11-23 4:26 ` Dave Chinner
2016-11-23 13:55 ` Zygo Blaxell
2016-11-23 22:13 ` Dave Chinner
2016-11-23 23:14 ` Zygo Blaxell
2016-11-23 23:53 ` Dave Chinner
2016-11-24 1:26 ` Darrick J. Wong
2016-11-25 4:20 ` Zygo Blaxell
2016-11-28 17:58 ` Darrick J. Wong
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=cover.1479427384.git.osandov@fb.com \
--to=osandov@osandov.com \
--cc=darrick.wong@oracle.com \
--cc=hch@infradead.org \
--cc=kernel-team@fb.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=quwenruo@cn.fujitsu.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.