Re: BTRFS file clone support for cp

[Chris Mason]

On Wed, Jul 29, 2009 at 12:10:14PM -0400, Chris Mason wrote:
> On Wed, Jul 29, 2009 at 03:14:49PM +0100, Pádraig Brady wrote:
> > Chris Mason wrote:
> > > On Tue, Jul 28, 2009 at 10:06:35PM +0200, Giuseppe Scrivano wrote:
> > >>
> > >> I can't replicate it now, all tests I am doing report that blocks used
> > >> before and after the clone are the same.  Probably yesterday the
> > >> difference I noticed was in reality the original file flushed to the
> > >> disk.
> > > 
> > > The clone will use some additional space for the metadata required to
> > > point to the cloned blocks.  It isn't exactly O(1) it is O(metadata for
> > > the file).
> > 
> > Thanks for the clarification Chris.
> > So the just committed change in cp will
> > link the destination file to the extents of the source.
> > 
> > We may need to play around with fallocate()
> > if we want to get back to the original
> > cp semantics of actually allocating space
> > on the file system for the new file.
> 
> Well, best to just use the original cp code.  I was talking with
> Giuseppe about this as well, I think we should the option to do regular
> cp via a flag.
> 
> There will soon be a reflink system call that can be used on ocfs2 and
> btrfs as well.  Thanks for adding this to glibc!

Um, cp, not glibc, sorry ;)

-chris