(triaging old bugs)
On 14/05/12 07:19 AM, Pádraig Brady wrote:
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:
[...]
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.
In 2014 we had this commit:
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=b47231be6813e6cb5305266e391b4bb745f27f13
====
commit b47231be6813e6cb5305266e391b4bb745f27f13
Author: David Sterba <dste...@suse.cz>
Date: Wed Sep 24 11:15:05 2014 +0100
mv: use reflink=auto mode by default
On some filesystems (BTRFS), moving a file within the filesystem may
cross subvolume boundaries and we can use a lightweight reflink copy,
similar to what cp(1) can do, which is faster than a full file copy.
====
Does this 'reflink=auto' mode addresses OCFS2 as well?
I believe so, but want to double-check.
If there are no objections, I'll mark this as "fixed/done" in couple of
days.
regards,
- assaf
