[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#6048: bug#11443: linux "cp" and ocfs2 reflink/clone/fastcopy/copy on
bug#6048: bug#11443: linux "cp" and ocfs2 reflink/clone/fastcopy/copy on write
Mon, 14 May 2012 14:19:42 +0100
Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0
I've merged this back to bug 6048
On 05/09/2012 03:28 PM, Kai Petzke wrote:
> 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:
> 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.
> 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?
Description: Text document