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
