I think this looks better and fits in the existing xml format/model...
comments invited
<volumes>
<volume>
.....
.....
<name> bd </name>
.....
.....
<backend> block </backend>
<capabilities>
<capability> thin </capability>
<capability> writesame </capability>
</capabilities>
.....
.....
</volume>
<backend> indicates the volume support block devices and <capabilities>
indicate the different features available in the volume. Seeing that
VDSM (or any mgmt app/client) can know of them and use them instead of
doing it locally.
For eg: WS can be exploited by VDSM and help provide pre-allocated vm
disk images in efficient way
thanx,
deepak
On 05/17/2013 12:55 PM, M. Mohan Kumar wrote:
Hello,
We are planning to add capability information to gluster volume info CLI
output so that VDSM/management entity can accordingly exploit the
gluster volume.
For example when a gluster volume is created with BD xlator, VDSM should
be aware that this gluster volume can create LVs to host VM images and
it has to use special xattr command to trigger creating LVs in this
volume. So if gluster volume info gives hint about the capability of a
volume, VDSM can use them.
For example snip of gluster volume info output for a BD xlator volume:
Volume Name: bd
Type: Distribute
Volume ID: 17a9999e-ca40-49f4-aa1f-dab4556041d9
Status: Created
Capabilities:
Capability 1: BD
Number of Bricks: 1
Transport-type: tcp
Bricks:
Brick1: /storage/bd
Brick1: VG: VG1
When posix/bd xlator capable of doing some scsi offload functionalities
such as write same, unmap etc these capabilities will also be shown as
part of the capabilities. For example a volume capable of writesame
feature [only snip of capability line]:
Capabilities:
Capability 1: BD
Capability 2: WRITESAME
Here "Capability 1:" is used to inform its a BD xlator based volume and
for posix volume it will be "POSIX". Instead can "Backend" be used to
inform if its BD or posix?
So VDSM can exploit the writesame feature instead of doing expensive dd
if=/dev/zero of=<path> for creating a zeroed image. Similarly VDSM can
exploit other features such as UNMAP/DISCARD to release the data blocks
after a file is deleted inside VM in thin provisioned storage.
Need to decide the xml hierachy for capabilities. Here is my proposal
For a posix based volume file:
<capability>
<xlator name="posix">
</xlator>
</capability>
For a BD based volume file informing it can thin provision and writesame
blocks:
<capability>
<xlator name="bd">
<type>thin</type>
<type>writesame</type>
</xlator>
</capability>
We use xlator tag inside capability to inform what kind of volume is
this one: posix or BD. Do we have better alternate for informing this?
Something like:
<backend>bd</backend>
<capability>
<xlator name="bd">
<type>thin</type>
<type>writesame</type>
</xlator>
</capability>
