On 07/24/2013 07:55 PM, Federico Simoncelli wrote:
----- Original Message -----
> From: "Federico Simoncelli" <fsimonce(a)redhat.com>
> To: "Itamar Heim" <iheim(a)redhat.com>
> Cc: "Deepak C Shetty" <deepakcs(a)linux.vnet.ibm.com>,
vdsm-devel(a)lists.fedorahosted.org, "Ayal Baron"
> <abaron(a)redhat.com>
> Sent: Wednesday, July 24, 2013 4:22:02 PM
> Subject: Re: [vdsm] Exploiting domain specific offload features
> ----- Original Message -----
>> From: "Itamar Heim" <iheim(a)redhat.com>
>> To: "Federico Simoncelli" <fsimonce(a)redhat.com>
>> Cc: "Deepak C Shetty" <deepakcs(a)linux.vnet.ibm.com>,
>> vdsm-devel(a)lists.fedorahosted.org
>> Sent: Wednesday, July 24, 2013 3:35:35 PM
>> Subject: Re: [vdsm] Exploiting domain specific offload features
>>
>> On 07/24/2013 03:38 PM, Federico Simoncelli wrote:
>>> I think we can already start exploiting cloning whenever we need to copy
>>> a volume maintaining the same format (raw=>raw, cow=>cow).
>>>
>> you still need to tailor the flow from engine's perspective, right?
>> or just override the entity created by the engine with the native cloned
>> one for simplicity?
> No, this change would be transparent to the engine. When vdsm is asked to
> clone/copy an image (eg. iirc create a non-thin-provisioned vm from template)
Maybe in this case we use an hard-link (no time to check now). Anyway concept is
that if we ever need to copy a volume within the same storage domain, that can be
offloaded to gluster.
I am not sure if its clear, but wanted to stress that when Gluster
provides the clone/snapshot
offloads.. the new files (which map to LVs as Gluster is configured with
block backend) will be seen as
normal files on the Gluster mount (aka Gluster storage domain). But VDSM
expects the snapshot
to appear as base <-- qcow2 in the FS domain, which won't happen in this
case. Will something
break in engine/VDSM assumptions and/or flows when this happens ?
thanx,
deepak
> it would use the gluster clone capability to offload the volume copy.