From: Li Dongyang <jerry87905@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: cp --reflink with Btrfs
Date: Wed, 16 Dec 2009 14:27:53 +0800 [thread overview]
Message-ID: <4b287dd5.5744f10a.3536.2011@mx.google.com> (raw)
In-Reply-To: <hg96k6$q17$1@ger.gmane.org>
Have a look at line 998, ioctl.c, inside btrfs_ioctl_clone(),
the src->i_size(the size of the testfile created by touch) is just 0, and this
will cause btrfs_ioctl_clone just return -EINVAL.
I'm not sure if it makes sense to clone a file which actually doesn't have any
data extents.
On Wednesday 16 December 2009 07:37:42 Jason White wrote:
> Josef Bacik <josef@redhat.com> wrote:
> >On Sun, Dec 13, 2009 at 12:29:03AM +0000, Jason White wrote:
> >> I am testing a Btrfs root file system with Debian (kernel 2.6.32) under
> >> KVM.
> >>
> >> jason@vrtl:~$ touch testfile
> >> jason@vrtl:~$ cp --reflink testfile /tmp
> >> cp: failed to clone `/tmp/testfile': Invalid argument
> >>
> >> This is with GNU Coreutils 8.0 taken from debian Sid.
> >>
> >> Is this a Coreutils issue, a Btrfs problem or something in my local
> >> configuration?
> >
> >Try using bcp, if that works then its likely a problem with coreutils.
>
> After reporting this to Debian and engaging on follow-up discussion, it
> turns out that bcp copies the data if the ioctl() call to clone the file
> fails, as can be seen from the Python code (which I should have read, but
> didn't...).
>
> Unfortunately the ioctl() call is failing both in bcp and in cp --reflink.
>
> Here's partial strace output from the latter.
>
> cp --reflink testfile testfile2
>
> open("testfile", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
> open("testfile2", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
> fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
> ioctl(4, 0x40049409, 0x3) = -1 EINVAL (Invalid argument)
>
> Kernel 2.6.32 (debian Sid), x86-64 architecture.
>
> Suggestions welcome.
>
> Debian bug report:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561225
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2009-12-16 6:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-13 0:29 cp --reflink with Btrfs Jason White
2009-12-14 16:23 ` Josef Bacik
2009-12-15 23:37 ` Jason White
2009-12-16 6:27 ` Li Dongyang [this message]
2009-12-16 17:55 ` Sage Weil
-- strict thread matches above, loose matches on Subject: below --
2010-01-27 10:53 Andreas Barth
2010-01-28 21:09 ` Chris Mason
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=4b287dd5.5744f10a.3536.2011@mx.google.com \
--to=jerry87905@gmail.com \
--cc=linux-btrfs@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 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.