<html><head/><body><html><head></head><body>We will bring this up at the next board meeting and vote on it. John Mark will reply with the date of that next meeting. <br>
<br>
Until that time, this topic is dead.<br>
<br>
DO post new topics to offer POSITIVE suggestions as to how it could be implemented, offer to contribute to that end, and provide proof of concepts. <br>
<br>
DO NOT hijack another support thread. If you do so you will be banned. <br><br><div class="gmail_quote">Stephan von Krawczynski <skraw@ithnet.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre style="white-space: pre-wrap; word-wrap:break-word; font-family: sans-serif; margin-top: 0px">On Sun, 13 Jan 2013 07:11:14 -0800<br />Joe Julian <joe@julianfamily.org> wrote:<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">On 01/13/2013 04:14 AM, glusterzhxue wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">Hi all,<br />We placed Virtual Machine Imame(based on kvm) on gluster file system, <br />but IO performance of the VM is only half of the bandwidth.<br />If we mount it on a physical machine using the same volume as the <br />above VM, physical host reaches full bandwidth. We performed it many <br />times, but each had the same result.<br /></blockquote>What you're seeing is the difference between bandwidth and latency. When <br />you're writing a big file to a VM filesystem, you're not performing the <br
/>same operations as writing a file to a GlusterFS mount thus you're able <br />to measure bandwidth. The filesystem within the VM is doing things like <br />journaling, inode operations, etc. that you don't have to do when <br />writing to the client requiring a lot more I/O operations per second, <br />thus amplifying the latency present in both your network and the context <br />switching through FUSE.<br /><br />You have two options:<br />1. Mount the GlusterFS volume from within the VM and host the data <br />you're operating on there. This avoids all the additional overhead of <br />managing a filesystem on top of FUSE.<br />2. Try the 3.4 qa release and native GlusterFS support in the latest <br />qemu-kvm.</blockquote><br />Thank you for telling the people openly that FUSE is a performance problem<br />which could be solved by a kernel-based glusterfs.<br /><br />Do you want to make drivers for every application like qemu? How many burnt<br />manpower will it take until the
real solution is accepted?<br />It is no solution to mess around _inside_ the VM for most people, you simply<br />don't want _customers_ on your VM with a glusterfs mount. You want them to see<br />a local fs only.<br /></pre></blockquote></div></body></html></body></html>