Re: BTRFS file clone support for cp

[Jim Meyering]

Pádraig Brady wrote:

> Giuseppe Scrivano wrote:
>> Hello,
>>
>> the BTRFS file system, avaiable on Linux since its 2.6.29 version,
>> supports file cloning.  This simple patch adds the support for this
>> feature to the cp utility.
>
> Right, so using the COW feature of BTRFS to speed up copies,
> and reduce space by only writing blocks that need to be changed.
> Cool!
>
>>>From deea0ee0c2a521aae5a89d8613f937707d8f0e7b Mon Sep 17 00:00:00 2001
>> From: Giuseppe Scrivano <address@hidden>
>> Date: Sat, 25 Jul 2009 16:35:27 +0200
>> Subject: [PATCH] cp: support the btrfs file system clone operation.
>
> This could apply to `install` also.
>
>> +#ifdef __linux__
>> +  /* Try a btrfs clone operation.  If the operation is not supported
>> +     or it fails then copy the file in the usual way.  */
>> +  if (!ioctl (dest_desc, 1074041865, source_desc))
>> +    copied = true;
>> +#endif
>
> I'm a little worried about doing it unconditionally.
> At first I was worried about deferring the copy operation
> to the process that's going to be modifying the data.
> But then realised going to be reading and writing the data anyway.
> One caveat though is, with this scheme it could be reading from
> and writing to different parts of a mechanical disk which could
> be slower due to seeking.
>
> Another possible issue with this I can think of is
> depending on the modification pattern of the COW files,
> the modification processes could fragment the file or
> more seriously be given ENOSPC errors.

I hope btrfs takes care of this behind the scene.

How does the clone work wrt to space consumed, a la df?
If copying a 1GB file this way does not update usage
stats to reflect the additional 1GB of space used, ...

> One could alleviate the last issues by using fallocate()
> on the destination, and patch for which is already written
> and hopefully we can get in soon (we're waiting on some
> clarifcation of the fallocate() interface). Note the fallocate
> patch only calls fallocate() when creating holes is not attempted.
> I.E. --sparse=never or --sparse=auto when the disk usage indicates
> that no holes are present.
>
> So perhaps we should hold off on this patch until
> the fallocate one goes in also?

If all I need to clone a huge file is the inode (and no blocks),
then yes, we'll have to wait.