Re: [Gluster-devel] Adding capability information to gluster volume info output

[Deepak C Shetty]

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>