GNU bug report logs - #24399
FICLONE for coreutils; copy_file_range?

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 24399 in the body.
You can then email your comments to 24399 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: bug-coreutils <at> gnu.org
Subject: FICLONE for coreutils; copy_file_range?
Date: Fri, 9 Sep 2016 15:46:14 -0700

[Message part 1 (text/plain, inline)]

I installed the attached patch so that cp etc. can use the FICLONE API 
that appears to be what the Linux kernel has standardized on for this 
sort of thing.

I notice that the Linux 4.5 kernel has added a copy_file_range syscall 
that is said to clone in some cases, but this isn't yet declared in the 
/usr/include headers on Fedora 24 (4.7.2 kernel). Also, its man page 
says it uses a size_t (not off_t) to count the number of bytes to be 
copied, which is a strange choice for a file-copying API. What's up with 
that?

[0001-cp-use-FICLONE-instead-of-BTRFS_IOC_CLONE.patch (application/x-patch, attachment)]

Message #8 received at 24399 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, 24399 <at> debbugs.gnu.org
Subject: Re: bug#24399: FICLONE for coreutils; copy_file_range?
Date: Sat, 10 Sep 2016 11:05:00 +0100

On 09/09/16 23:46, Paul Eggert wrote:
> I installed the attached patch so that cp etc. can use the FICLONE API 
> that appears to be what the Linux kernel has standardized on for this 
> sort of thing.

Nice thanks.
This is just renaming as the kernel used
the same ABI as for the BTRFS ioctl.

> I notice that the Linux 4.5 kernel has added a copy_file_range syscall 
> that is said to clone in some cases, but this isn't yet declared in the 
> /usr/include headers on Fedora 24 (4.7.2 kernel). Also, its man page 
> says it uses a size_t (not off_t) to count the number of bytes to be 
> copied, which is a strange choice for a file-copying API. What's up with 
> that?

I've been monitoring that syscall a bit.
It will be very useful for efficient server side only copying,
and can take advantage of reflinking where available.
I was pushing for more control flags for dealing with reflinking
and handling of holes, but that was rejected in the first iteration at least.
One quite awkward thing at present is if the file system doesn't
implement the syscall, it falls back to do_splice_direct
which is basically sendfile(), and that will expand holes.

thanks,
Pádraig

Message #11 received at 24399 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>, 24399 <at> debbugs.gnu.org
Subject: Re: bug#24399: FICLONE for coreutils; copy_file_range?
Date: Sat, 10 Sep 2016 19:18:17 -0700

Pádraig Brady wrote:

> One quite awkward thing at present is if the file system doesn't
> implement the syscall, it falls back to do_splice_direct
> which is basically sendfile(), and that will expand holes.

OK, thanks for the info. It sounds like copy_file_range is not ready for 
prime-time, then. Its use of a size_t to represent a file size seems like it is 
obviously wrong, as well.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.