----- Original Message -----
> From: "Itamar Heim" <ih...@redhat.com>
> To: "Federico Simoncelli" <fsimo...@redhat.com>
> Cc: "Deepak C Shetty" <deepa...@linux.vnet.ibm.com>,
> 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:
> > ----- Original Message -----
> >> From: "Deepak C Shetty" <deepa...@linux.vnet.ibm.com>
> >> To: email@example.com
> >> Sent: Wednesday, July 17, 2013 12:08:03 PM
> >> Subject: Re: [vdsm] Exploiting domain specific offload features
> >> On 07/17/2013 12:48 PM, M. Mohan Kumar wrote:
> >>> Hello,
> >>> We are adding features such as server offloaded cloning, snapshot of
> >>> the files(ie VM disks) and zeroed vm disk allocation in GlusterFS. As of
> >>> now only BD xlator supports offloaded cloning & snapshot. Server
> >>> offloaded zeroing of VM disks is supported both by posix and BD xlator.
> >>> The initial approach is to use xattr interface to trigger this offload
> >>> features such as
> >>> # setfattr -n "clone" -v "path-to-new-clone-file" path-to-source-file
> >>> will create clone of path-to-source-file in path-to-new-clone-file.
> >>> Cloning is done in GlusterFS server side and its kind of server
> >>> offloaded copy. Similarly snapshot can also be taken using setfattr
> >>> approach.
> >>> GlusterFS storage domain is already part of VDSM and we want to exploit
> >>> offload features provided by GlusterFS through VDSM. Is there any way to
> >>> exploit these features from VDSM as of now?
> >> Mohan,
> >> IIUC, zeroing of files in GlusterFS is supported for both posix and
> >> block backends of GlusterFS
> >> Today VDSM does zeroing (as part of preallocated vmdisk flow) itself
> >> using 'dd'. If GlusterFS supports
> >> zeroing.... this feature can be exploited in VDSM (by overriding create
> >> volume flow as needed) so that we can save
> >> compute resources on the VDSM host, when Gluster domain is being used.
> >> Regarding exploiting clone and snapshot, IIUC these are very native
> >> to VDSM today... it expects that snapshots are qcow2 based and they form
> >> the image chain etc... With snapshot and clone handled in Gluster
> >> transparently, these
> >> notions of VDSM will be broken, so it probably needs a lot of changes in
> >> lots of places in VDSM to exploit these.
> >> Federico/Ayal,
> >> Wanted to know your comments/opinion on this ?
> >> Is there a way to exploit these features in VDSM Gluster storage domain
> >> in an elegant way ?
> > 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)
it would use the gluster clone capability to offload the volume copy.
vdsm-devel mailing list