Re: BTRFS file clone support for cp

[Jim Meyering]

Giuseppe Scrivano wrote:
> Jim Meyering <address@hidden> writes:
>
>> Doesn't that constant, 1074041865, have a symbolic name?
>> Maybe BTRFS_IOC_CLONE?
>
> Yes, it is exactly BTRFS_IOC_CLONE and it is defined in the
> fs/btrfs/ioctl.h file.
>
>
>>> Is there an easy and quick way to determine which file system is used by
>>> a file?  Probably it would be safer to add a guard around the ioctl
>>> call.
>>
>> Before thinking about that, I'd like to know the approximate cost
>> of the failing ioctl, e.g., on a kernel with btrfs support and
>> on one without, in case that makes a difference.  I.e., what impact
>> would it have if left unprotected?  Does it make a measurable difference
>> when copying 20K empty files on a tmpfs file system?
>>
>> If necessary, we can avoid almost all of the per-file ioctl calls
>> via a map that associates each distinct device number encountered
>> with a boolean "is btrfs file system".  gnulib's fts does something
>> similar, but its goal is to determine whether a different FS-specific
>> performance optimization is likely to help.
>
> I didn't notice any difference using a patched and an un-patched cp on
> tmpfs.
...
> With 10000000 iterations:
>
> 0.68user 0.82system 0:01.50elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (0major+119minor)pagefaults 0swaps

Good.  That seems negligible.

However, but what about cp's --sparse option?
btrfs supports sparse files, so this new code will have to
honor that.  The trouble is that there is currently no option
to say "preserve precisely and only whatever holes are present
in src", which is the behavior I would expect from that ioctl.

I am inclined to extend the definition of --sparse=auto (the default)
to mean "make as faithful a copy as possible (btrfs clone), and failing
that, use the sparse-preserving heuristic".  Then we can use the new
ioctl in the default case.  The down side of such a move is that it would
induce a subtle change in behavior: whereas before, a partially-sparse
file would be copied (assuming btrfs FS src and dest) to a fully-sparse
destination, now, you'll get a mirror image, partially-sparse copy.
But seeing as how btrfs is so new, there is little legacy to worry about.
And besides, for a command whose job it to copy, a feature to permit
more faithful copying is hard to turn down or relegate to non-default
status.