bug#6048: bug#11443: linux "cp" and ocfs2 reflink/clone/fastcopy/copy on write

[Pádraig Brady]

I've merged this back to bug 6048

On 05/09/2012 03:28 PM, Kai Petzke wrote:
> Hello,
> 
> 
> there has been work by others about adding support for the OCFS2 "reflink" 
> ioctl() call, which is similiar to the btrfs "clone" call, and creates a 
> copy-on-write copy of the original, thus allowing to "copy" even gigabyte 
> sized files within a tiny fraction of a second, and without using much 
> additional file system space. See:
>     http://lists.gnu.org/archive/html/coreutils/2011-08/msg00046.html
>     http://lists.gnu.org/archive/html/bug-coreutils/2010-04/msg00185.html
> 
> I have updated those patches to work against coreutils 8.16, removed those 
> bugs, that I spotted. In particular, if the destination file exists, the 
> "reflink" ist automatically tried again after removing it, and if not all 
> attributes are copied, it is made sure, that the following open() system call 
> does not truncate the just created copy.
> 
> I strongly suggest including that patch in the coreutils package,

I'm less enthused about adding this as it doesn't fit very cleanly.

> even though the interface to use to different system calls to achieve the 
> same thing is awkward.
> But, as laid out in the comments in the source, btrfs clone and ocfs2 reflink 
> are semantically
> quite different, so that unifying them into one on the kernel side is not 
> likely to happen, soon, if it happens at all.

That would be unfortunate. Hopefully a generic reflink() call can be sorted out.

> If users don't use the --reflink option of "cp", the additional code makes no 
> difference, so it doesn't hurt.

Fair point.

> And if users use "--reflink" on either of the supported file systems, they 
> get a huge advantage out of it!

I really dislike that xattrs are copied unconditionally.
It might be best to auto clear xattrs after the "reflink", if possible?

cheers,
Pádraig.

coreutils-8.16-ocfs2-reflink.diff
Description: Text document