Hi Josh, On Thu, 10 Mar 2016 14:45:38 -0800, 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. Currently the copy is being done on the LIO iSCSI gateway, so offloading any of that to the OSDs would save a lot of network traffic. Also as Ric mentioned, XFS has clone-range support coming, so Ceph's dedupe COW optimisations need not only be limited the Btrfs Filestore. > 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. Okay, fair enough. Thanks for the details. Cheers, David -- 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
