Re: BTRFS file clone support for cp

[Chris Mason]

On Tue, Jul 28, 2009 at 10:06:35PM +0200, Giuseppe Scrivano wrote:
> Hi Pádraig,
> 
> 
> Pádraig Brady <address@hidden> writes:
> 
> > How different exactly?
> > OK I tried this myself on F11 with inconclusive results.
> 
> 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).

> 
> 
> > The above suggests that the clone does actually allocate space
> > but btrfs isn't reporting it through statvfs correctly?
> 
> The same message appeared here too some days ago, though I cloned only
> few Kb files, not much to fill the entire partition.
> 
> 
> > If the clone does allocate space, then how can one
> > clone without allocation which could be very useful
> > for snapshotting for example?
> 
> I don't know if snapshotting is handled in the same way as a "clone",
> but in this case it seems more obvious to me that no additional space
> should be reported.

The COW for snapshotting and a clone are the same, but the way we get
there is a little different.  For a snapshot, we have two btree roots
pointing to the same nodes, and we've incremented the reference count on
each of the nodes they both point to.  No matter how big the subvolume
is, this will always be O(number of pointers in the root block).

Cloning a file is done by walking the file metadata and taking a
reference on each extent pointed to by the file.  The file data is never
read in, but all of the file metadata is read in.

> 
> 
> > Also I tried the above twice and both times got:
> > http://www.kerneloops.org/submitresult.php?number=578993
> 
> I didn't get these errors.  I am using the btrfs git version.

These have been fixed.

-chris