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.
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.
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?
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.
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.
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
ok, closing. Please reopen if still relevant/you want to work on it.