Re: BTRFS file clone support for cp

[Ric Wheeler <rwheeler@redhat.com>]

On 07/30/2009 04:40 AM, P=C3=A1draig Brady wrote:
> Jim Meyering wrote:
>   =20
>> Joel Becker wrote:
>>
>>     =20
>>> On Wed, Jul 29, 2009 at 07:14:37PM +0100, P=C3=A1draig Brady wrote:
>>>       =20
>>>> 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=3D{soft,hard,cow}
>>>> for symlink(), link() and reflink() respectively?
>>>> I.E. link to the name, inode or extents respectively.
>>>>         =20
>>> 	I've cooked up 'ln -r' for reflinks, which works for ln(1) but
>>> not for cp(1).
>>>       =20
>> Thanks.  I haven't looked, but after reading about the reflink sysca=
ll
>> [http://lwn.net/Articles/332802/] had come to the same conclusion:
>> this feature belongs with ln rather than with cp.
>>     =20
>
> Right. It definitely should be in ln anyway.
>
>   =20
>> Besides, putting the new behavior on a new option avoids
>> the current semantic change we would otherwise induce in cp.
>>     =20
>
> 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...
>
>   =20

I think that doing reflink by default would be a horrible idea - one=20
good reason to copy a file is to increase your level of fault tolerance=
=20
and reflink magically avoids that :-)

reflink is a neat feature, but should be used on purpose in my opinion,

ric

> In any case putting --link=3Dcow or --reflink or whatever in cp
> could be very useful for creating writeable snapshot branches.
>
> cheers,
> P=C3=A1draig.
>   =20

--
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