Bug 1069557 (RHEV_clone_disk_with_xcopy)

Summary:	[RFE] disk clone: use xcopy if available (depends on platform BZ for qemu-img to support xcopy - bug 1482537)
Product:	[oVirt] vdsm	Reporter:	Federico Simoncelli <fsimonce>
Component:	RFEs	Assignee:	Dan Kenigsberg <danken>
Status:	CLOSED DEFERRED	QA Contact:	Avihai <aefrat>
Severity:	high	Docs Contact:
Priority:	high
Version:	---	CC:	acanan, bugs, ebenahar, jcall, jharriga, kwolf, lpeer, nsoffer, srevivo, sweil
Target Milestone:	---	Keywords:	FutureFeature, TestOnly
Target Release:	---	Flags:	ylavi: ovirt-4.3? ylavi: planning_ack+ rule-engine: devel_ack? rule-engine: testing_ack?
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Storage	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1482537, 1594820
Bug Blocks:	1314382

Description Federico Simoncelli 2014-02-25 09:44:47 UTC

Description of problem:
Currently vdsm uses dd to zero out and copy volumes. Both operations could be carried out more efficiently using advanced storage capabilities like write-same and extended-copy. For reference the zerofill support was added to gluster in bug 1028673.

It would be best to have a tool with write-same and extended-copy support (when available) to be use transparently on file domains (nfs, glusterfs) and block domains (iscsi, fcp). For block domains we'll probably need the support in dm/lvm.

Comment 1 Zach Brown 2014-02-25 18:00:12 UTC

Some quick thoughts:

The way this is done now is with storage target specific knowledge.  For example, today you could use the btrfs clone ioctl to share regions of files or ocfs2 reflink ioctl to clone entire files.  So in the immediate future you could certainly continue down that path.

In the long term we're working on a system call that lets you copy byte ranges between open files.  It's gone through a few iterations.  I'll have another iteration sent to -fsdevel soon, I hope.  It'll probably take a while for the interface to be negotiated and merged so I'm not sure when this would be realistically available.

Comment 7 Nir Soffer 2017-11-26 17:06:52 UTC

I want to use single tool for image copying, and the tool is qemu-img. If the copy
can be faster by using low level SCSI commands, it should be implemented in
qemu-img.

Kevin, what do you think?

Comment 8 Kevin Wolf 2017-11-27 10:20:47 UTC

Makes sense in theory, though I've never played with xcopy, so I can't say what it looks like in practice.

Are there kernel interfaces, and preferably generic ones, for efficient copying? If not, do we need a kernel BZ? I can't imagine qemu directly sending SCSI commands to a device that is in use by Linux.

Comment 10 Sandro Bonazzola 2019-01-28 09:44:31 UTC

This bug has not been marked as blocker for oVirt 4.3.0.
Since we are releasing it tomorrow, January 29th, this bug has been re-targeted to 4.3.1.

Comment 11 Michal Skrivanek 2020-03-18 15:50:20 UTC

This bug didn't get any attention for a while, we didn't have the capacity to make any progress. If you deeply care about it or want to work on it please assign/target accordingly

Comment 12 Michal Skrivanek 2020-03-18 15:52:55 UTC

This bug didn't get any attention for a while, we didn't have the capacity to make any progress. If you deeply care about it or want to work on it please assign/target accordingly

Comment 13 Michal Skrivanek 2020-04-01 14:49:03 UTC

ok, closing. Please reopen if still relevant/you want to work on it.

Comment 14 Michal Skrivanek 2020-04-01 14:52:00 UTC

ok, closing. Please reopen if still relevant/you want to work on it.