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@xxxxxxxxx> 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@xxxxxxxxxx
https://lists.nongnu.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxx
https://lists.nongnu.org/mailman/listinfo/gluster-devel
