On 03/11/2016 04:15 AM, Josh Durgin wrote:
On 03/10/2016 04:04 AM, David Disseldorp wrote:
On Thu, 10 Mar 2016 00:36:55 -0600, Mike Christie wrote:
...
This does not include support for XCOPY/extended copy. I
am still looking into this, but it seems it might be
difficult to support due to rbd being more tuned to cloning
entire devices. When we implement VASA, the cloneVirtualVolume
might be something we can support though.
I suppose the src-and-dest-in-same-pg requirement would complicate
things quite a bit, but wouldn't clonerange be an option for XCOPY
offloads?
It's not a good fit, since with multiple clones putting data on the
same set of osds, the workload and space utilization gets skewed for
that set of osds compared to the rest of the cluster.
It also won't give you fast cloning - it's a full copy on xfs, and
you'd need to do one for every object affected.
Note that XFS is working on reflink code at the moment and that the kernel
people are looking at new system calls that will allow copy offload generically.
Specifically, that will give XFS (and other file systems like btrfs) the ability
to do a zero data movement pseudo copy (copy on write version) of a file.
That would make this interesting I think to think about doing...
Regards,
Ric
Due to these limitations, lack of existing clonerange use, and the
complications it brings to the osd as the only op affecting more than
one object, we've talked about removing the clonerange op.
Josh
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
