Re: BTRFS file clone support for cp

[Ric Wheeler]

On 07/30/2009 04:40 AM, Pádraig Brady wrote:
> 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...
>
>    

I think that doing reflink by default would be a horrible idea - one 
good reason to copy a file is to increase your level of fault tolerance 
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=cow or --reflink or whatever in cp
> could be very useful for creating writeable snapshot branches.
>
> cheers,
> Pádraig.
>