On 07/24/2013 03:38 PM, Federico Simoncelli wrote:

----- Original Message -----
From: "Deepak C Shetty" <deepa...@linux.vnet.ibm.com>
To: vdsm-devel@lists.fedorahosted.org
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:

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

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?

      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.

      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?
vdsm-devel mailing list

Reply via email to