From: Matt Robinson <git@nerdoftheherd.com>
To: Chris Mason <clm@fb.com>, David Sterba <dsterba@suse.cz>,
Josef Bacik <jbacik@fb.com>
Cc: Matt Robinson <git@nerdoftheherd.com>,
linux-btrfs@vger.kernel.org, Mark Fasheh <mfasheh@suse.de>,
Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
Subject: Re: [PATCH 1/1] btrfs: Align EOF length to block in extent_same
Date: Sat, 11 Apr 2015 20:17:07 +0100 [thread overview]
Message-ID: <CABJ34CLq5uvf0WGbo_EJz6Zz2aSxBjsXT6Re8m_Vd+BHuq2VKg@mail.gmail.com> (raw)
In-Reply-To: <20150303002720.GA26622@hungrycats.org>
Hi All,
As David hasn't got back to me I'm guessing that he is too busy with
other things at present. If anyone else is able to spare the time to
review my patch and give me feedback that would be very much
appreciated.
Many Thanks,
Matt
On 3 March 2015 at 00:27, Zygo Blaxell <ce3g8jdj@umail.furryterror.org> wrote:
>
> I second this. I've seen the same behavior.
>
> Clone seems to have evolved a little further than extent-same knows about.
> e.g. there is code in the extent-same ioctl that tries to avoid doing
> a clone from within one inode to elsewhere in the same inode; however,
> the clone ioctl (which extent-same calls) has no such restriction.
>
> As Matt mentioned, clone_range seems quite happy to accept a partial block
> at EOF. cp --reflink would be much harder to use if it did not.
>
> On Mon, Mar 02, 2015 at 08:59:11PM +0000, Matt Robinson wrote:
> > Hi David,
> >
> > Have you had a chance to look at this? Am very happy to answer
> > further questions, adjust my implementation, provide a different kind
> > of test case, etc.
> >
> > Many Thanks,
> >
> > Matt
prev parent reply other threads:[~2015-04-11 19:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-26 18:05 [PATCH 1/1] btrfs: Align EOF length to block in extent_same Matt Robinson
2015-01-28 12:55 ` David Sterba
2015-01-28 19:46 ` Matt Robinson
2015-03-02 20:59 ` Matt Robinson
2015-03-03 0:27 ` Zygo Blaxell
2015-04-11 19:17 ` Matt Robinson [this message]
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=CABJ34CLq5uvf0WGbo_EJz6Zz2aSxBjsXT6Re8m_Vd+BHuq2VKg@mail.gmail.com \
--to=git@nerdoftheherd.com \
--cc=ce3g8jdj@umail.furryterror.org \
--cc=clm@fb.com \
--cc=dsterba@suse.cz \
--cc=jbacik@fb.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=mfasheh@suse.de \
/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).