From: Omar Sandoval <osandov@osandov.com>
To: Qu Wenruo <quwenruo@cn.fujitsu.com>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>,
fstests@vger.kernel.org, btrfs <linux-btrfs@vger.kernel.org>,
linux-xfs@vger.kernel.org
Subject: Re: About reflink len = 0 behavior
Date: Thu, 20 Oct 2016 08:47:33 -0700 [thread overview]
Message-ID: <20161020154733.GA5436@vader> (raw)
In-Reply-To: <94d643cc-fa49-4b20-b265-55d50af15e47@cn.fujitsu.com>
On Thu, Oct 20, 2016 at 03:50:46PM +0800, Qu Wenruo wrote:
> Add cc to new xfs mail list.
>
>
> At 10/20/2016 03:46 PM, Qu Wenruo wrote:
> > Hi Darrick, xfs guys and btrfs guys.
> >
> > Although such question is quite late as reflink generic tests are in
> > fstests for a long time, I'm still not sure what's the correct behavior
> > for reflink len = 0.
> >
> > Test case generic/182 is causing different output between btrfs and xfs.
> >
> > For btrfs, dedupe will just return 0 and check nothing, while for xfs
> > len == 0 means to check the whole file length.
> >
> > Both makes sense for me, for btrfs len = 0 behavior, it just follows
> > read/write functions.
> > And I assume xfs follows reflink behavior, when len is not specified,
> > then reflink the length of src file.
> >
> > But since it's a generic test, we need to unify the behavior.
> >
> > So, which one is the standard and which document should we follow for
> > such behavior definition?
> >
> > Thanks,
> > Qu
Hey, Qu,
I brought this up a few months back here [1], and I think the conclusion
was that consistency with clone (so the XFS behavior) was probably what
we wanted. I just forgot to follow up and figure out if it would break
any userspace programs in a way that mattered (I doubt it).
1: http://marc.info/?l=linux-btrfs&m=146828374631829&w=2
--
Omar
next prev parent reply other threads:[~2016-10-20 15:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-20 7:46 About reflink len = 0 behavior Qu Wenruo
2016-10-20 7:50 ` Qu Wenruo
2016-10-20 15:47 ` Omar Sandoval [this message]
2016-10-21 3:00 ` Darrick J. Wong
2016-10-21 5:54 ` Qu Wenruo
2016-10-21 10:09 ` Christoph Hellwig
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=20161020154733.GA5436@vader \
--to=osandov@osandov.com \
--cc=darrick.wong@oracle.com \
--cc=fstests@vger.kernel.org \
--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 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).