Re: Adding capability information to gluster volume info output

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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>






[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux