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/
