<div dir="ltr">Hi there,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 10, 2013 at 10:28 AM, Maciej Gałkiewicz <span dir="ltr"><<a href="mailto:macias@shellycloud.com" target="_blank">macias@shellycloud.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
I am also using glusterfs but for different purposes. I hope to<br>
replace it with cephfs when it will be production ready. What I<br>
dislike in Glusterfs is it's stability. Many times it was not working<br>
as expected during brick replacement which is crucial for me. I am<br>
taking about version 3.3.0 or previous. Management of many glusterfs<br>
volumes generated many problems for me:( I am looking forward to test<br>
3.4.0.<br>
<div class="im"><br></div></blockquote><div><br></div><div>I'm happy to help you test out 3.4. A lot has changed with it, and much of it affects the use cases you described, specifically libgfapi, the QEMU integration, Nova integration, and the block device translator. <br>

<br>Our dev process is now also much cleaner and inclusive - you can see the results of our recent 3.5 feature decisions here: <a href="http://www.gluster.org/community/documentation/index.php/Planning35">http://www.gluster.org/community/documentation/index.php/Planning35</a><br>

<br>Incidentally, you seem to be allergic to qcow2 files :)  We have some performance numbers that may be eye-opening to you (and many others).<br><br></div><div>As Jeff mentioned in his response, there are many benefits from a unified storage backend with file semantics that doesn't silo your data. Let me know if I can be of any help.<br>

</div><div><br></div><div>-John Mark Walker<br>Gluster Community Leader<br><br><br></div><div><br></div></div></div></div></div>