----- Original Message -----
> From: "Federico Simoncelli" <fsimo...@redhat.com>
> To: "Itamar Heim" <ih...@redhat.com>
> Cc: "Deepak C Shetty" <deepa...@linux.vnet.ibm.com>,
> email@example.com, "Ayal Baron"
> Sent: Wednesday, July 24, 2013 4:22:02 PM
> Subject: Re: [vdsm] Exploiting domain specific offload features
> ----- Original Message -----
> > From: "Itamar Heim" <ih...@redhat.com>
> > To: "Federico Simoncelli" <fsimo...@redhat.com>
> > Cc: "Deepak C Shetty" <deepa...@linux.vnet.ibm.com>,
> > firstname.lastname@example.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
offloaded to gluster.
> it would use the gluster clone capability to offload the volume copy.
vdsm-devel mailing list