gluster-devel
[Top][All Lists]
Advanced

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

Re: [Gluster-devel] [RFC] Generating custom volume files for gluster vol


From: Bharata B Rao
Subject: Re: [Gluster-devel] [RFC] Generating custom volume files for gluster volumes
Date: Mon, 30 Jul 2012 14:41:34 +0530

On Mon, Jul 30, 2012 at 11:50 AM, Vijay Bellur <address@hidden> wrote:
> On 07/26/2012 10:28 AM, Bharata B Rao wrote:
>
>>
>> Its already possible to specify a custom extension to the volume name
>> and glusterd picks the appropriate volume file. For eg, for a volname
>> of test.cust, glusterd is capable of picking test.cust.vol. We plan to
>> piggy back on this feature and name the custom volume files with
>> .custom extension.
>>
>> Typical gluster CLI commands needed could be like this:
>>
>> gluster> volume regenerate testvol custom --without-io-cache
>> --with-quick-read
>>
>> This would create testvol.custom without io-cache and with quick-read
>> xlators.
>>
>> This is just an example and not really cast in stone. Need community's
>> opinion on this. Should we use existing options like "volume set" or
>> invent new ones ?
>>
>
> I would prefer that we re-use "volume set" for the purpose of re-generating
> volume files.

Ok.

> I do not see the need to have multiple client volume files per
> volume for this use case.

Say gluster volume resides on machine A and QEMU runs on machine B. In
this case QEMU will use this custom client volfile.

address@hidden test]# cat test.cust.vol
volume test
    type protocol/client
    option remote-host A
    option remote-subvolume /test
    option transport-type tcp
end-volume

Note that instead of the custom client volfile, I could have used the
default client volfile too.

Next if QEMU migrates to A, then it will use this volume file:

address@hidden test]# cat test.rpcbypass.vol
volume test
    type storage/posix
    option directory /test
    option volume-id b1252bd2-410c-4b60-9807-57a61d43b356
end-volume

Hence there is a need to have multiple volume files for a given volume.

> Using the same volume for storing VM images and
> other data might not be a widespread use case. As such, the workload on the
> volume would be homogeneous and customizing the default volume file to serve
> this workload would be desirable.
>
> We are also evolving the notion of tags for volumes. A tag would provide the
> ability to bundle a bunch of "volume set" commands under an alias. A tag
> when applied to a volume would result in re-generation of volume files and
> the end result would be the same as having applied each of the volume set
> commands individually. You can probably define a tag and use that for the VM
> image store volume.

Sure, will take a look at the tag mechanism.

>
>
>
>> Should we allow such flexibility when creating volumes or should we
>> provide such capability only when regenerating volume files  for a
>> given volume ?
>
>
> It might be good to allow such flexibility while creating volumes too. This
> would mean that we will have to introduce additional keywords or provide
> switches for volume creation. Instead of adding new keywords to volume
> create, we can also look at enhancing tags to provide this behavioural
> change for a volume upon application of the tag. The feature page for volume
> tagging would be up for RFC shortly.

Mohan has started working on generating custom volume files. Will keep
you updated on how things turn up.

Regards,
Bharata.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]