Re: BTRFS file clone support for cp

[Pádraig Brady]

Jim Meyering wrote:
> Joel Becker wrote:
> 
>> On Wed, Jul 29, 2009 at 07:14:37PM +0100, Pádraig Brady wrote:
>>>
>>> At the moment we have these linking options:
>>>
>>> cp -l, --link #for hardlinks
>>> cp -s, --symbolic-link #for symlinks
>>>
>>> So perhaps we should support:
>>>
>>> cp --link={soft,hard,cow}
>>> for symlink(), link() and reflink() respectively?
>>> I.E. link to the name, inode or extents respectively.
>>
>>      I've cooked up 'ln -r' for reflinks, which works for ln(1) but
>> not for cp(1).
> 
> 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.

Right. It definitely should be in ln anyway.

> Besides, putting the new behavior on a new option avoids
> the current semantic change we would otherwise induce in cp.

Yes doing reflink() in cp by default currently can
be problematic as discussed, especially on mechanical hard disks.
Though in future I can see most users of cp preferring
reflink() to be done, rather than read()/write(). Ponder...

In any case putting --link=cow or --reflink or whatever in cp
could be very useful for creating writeable snapshot branches.

cheers,
Pádraig.