Re: BTRFS file clone support for cp

[Pádraig Brady]

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.

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?

cheers,
Pádraig.