[Gluster-devel] [RFC] Generating custom volume files for gluster volumes

[Joe Julian]

He wouldn't even have to do that in his user space. The feature page has 
it's own "talk" tab.

On 07/26/2012 10:19 AM, John Mark Walker wrote:
> Hi Bharata,
>
> It might make sense to start pushing this discussion and associated docs to the wiki, using the feature template. You could fill out the feature template, and then create a page in your user space as the feature "home" where you could point people to for any ongoing discussion. Sound good?
>
> For reference:
>
> Feature template: http://www.gluster.org/community/documentation/index.php/Features/Feature_Template
> Current new features list: http://www.gluster.org/community/documentation/index.php/Features
> See also 3.4 planning: http://www.gluster.org/community/documentation/index.php/Planning34
>
>
> -JM
>
>
> ----- Bharata B Rao<bharata.rao at gmail.com>  wrote:
>> Hi,
>>
>> I  have discussed this briefly with some gluster developers over IRC,
>> but thought of bringing this up here since I would like to propose
>> this as a feature for 3.4 once we have consensus on this.
>>
>> With QEMU supporting GlusterFS backend natively, it is good to
>>
>> - have a direct IO path from QEMU to its VM image on gluster backend
>> - optionally not use those client and server side translators that are
>> detrimental to VM's performance.
>>
>> If QEMU is running on the machine that hosts the brick, we could avoid
>> the overhead of client, server xlators and RPC communication
>> overhead by doing IO to the VM image directly using just the posix
>> xlator or any other leaf xlator as the case may be. Hence QEMU user
>> needs a general  capability to generate volume file with user
>> specified xlator set and specific capability to generate volume file
>> for RPC bypass scenario.
>>
>> 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 ?
>>
>> Should we allow such flexibility when creating volumes or should we
>> provide such capability only when regenerating volume files  for a
>> given volume ?
>>
>> I would like to know gluster community's thoughts and concerns on this
>> before starting work on this.
>>
>> Regards,
>> Bharata.
>> -- 
>> http://bharata.sulekha.com/blog/posts.htm, http://raobharata.wordpress.com/
>>
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/gluster-devel
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> https://lists.nongnu.org/mailman/listinfo/gluster-devel