Re: BTRFS file clone support for cp

[Jim Meyering]

Andi Kleen wrote:

> Jim Meyering <address@hidden> writes:
>>
>> Thanks.  I haven't looked, but after reading about the reflink syscall
>> [http://lwn.net/Articles/332802/] had come to the same conclusion:
>> this feature belongs with ln rather than with cp.
>
> cp already has -l so it would make sense to extend that too.

Good point.

>> Besides, putting the new behavior on a new option avoids
>> the current semantic change we would otherwise induce in cp.
>
> I don't see how semantics change in a user visible way.

With classic cp, if I copy a 1GB non-sparse file and there's less
space than that available, cp fails with ENOSPC.
With this new feature, it succeeds even if there are
just a few blocks available.

Also, consider (buggy!) code that then depends on being able to modify
that file in-place, and that "knows" it doesn't need to check for ENOSPC.
Sure, they should always check for write failure, but still.  It is
a change.