Re: BTRFS file clone support for cp

[Chris Mason <chris.mason@oracle.com>]

On Tue, Jul 28, 2009 at 10:06:35PM +0200, Giuseppe Scrivano wrote:
> Hi P=E1draig,
>=20
>=20
> P=E1draig Brady <P@draigBrady.com> writes:
>=20
> > How different exactly?
> > OK I tried this myself on F11 with inconclusive results.
>=20
> I can't replicate it now, all tests I am doing report that blocks use=
d
> 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).

>=20
>=20
> > The above suggests that the clone does actually allocate space
> > but btrfs isn't reporting it through statvfs correctly?
>=20
> The same message appeared here too some days ago, though I cloned onl=
y
> few Kb files, not much to fill the entire partition.
>=20
>=20
> > If the clone does allocate space, then how can one
> > clone without allocation which could be very useful
> > for snapshotting for example?
>=20
> 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 o=
n
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 neve=
r
read in, but all of the file metadata is read in.

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

These have been fixed.

-chris

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