<div dir="ltr"><div style>No, I am speaking about stranges in write to existing files. Maybe 'broken', but maybe root of trouble in my options (flush-behind or some else)? </div><div style><br></div><div style>Illtustration of my situation:</div>
<div style>root@virtual:~# rm testfile.bin # removing old file<br></div><div>root@virtual:~# dd if=/dev/zero of=testfile.bin bs=100M count=3 # testing speed on new file</div><div>3+0 records in</div><div>3+0 records out</div>
<div>314572800 bytes (315 MB) copied, 0.268943 s, 1.2 GB/s</div><div>root@virtual:~# dd if=/dev/zero of=testfile.bin bs=100M count=3 # testing speed on existing file. WOW! </div><div>3+0 records in</div><div>3+0 records out</div>
<div>314572800 bytes (315 MB) copied, 290.361 s, 1.1 MB/s</div><div><br></div><div style>Why writing to existing file is soooooooooooooooo slooooooooooooow?</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
2013/3/1 Brian Candler <span dir="ltr"><<a href="mailto:B.Candler@pobox.com" target="_blank">B.Candler@pobox.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Fri, Mar 01, 2013 at 03:30:07PM +0600, Nikita A Kardashin wrote:<br>
> If I try to execute above command inside virtual machine (KVM), first<br>
> time all going right - about 900MB/s (cache effect, I think), but if I<br>
> run this test again on existing file - task (dd) hungs up and can be<br>
> stopped only by Ctrl+C.<br>
> Overall virtual system latency is poor too. For example, apt-get<br>
> upgrade upgrading system very, very slow, freezing on "Unpacking<br>
> replacement" and other io-related steps.<br>
> Does glusterfs have any tuning options, that can help me?<br>
<br>
</div>If you are finding that processes hang or freeze indefinitely, this is not<br>
a question of "tuning", this is simply "broken".<br>
<br>
Anyway, you're asking the wrong person - I'm currently in the process of<br>
stripping out glusterfs, although I remain interested in the project.<br>
<br>
I did find that KVM performed very poorly, but KVM was not my main<br>
application and that's not why I'm abandoning it. I'm stripping out<br>
glusterfs primarily because it's not supportable in my environment, because<br>
there is no documentation on how to analyse and recover from failure<br>
scenarios which can and do happen. This point in more detail:<br>
<a href="http://www.gluster.org/pipermail/gluster-users/2013-January/035118.html" target="_blank">http://www.gluster.org/pipermail/gluster-users/2013-January/035118.html</a><br>
<br>
The other downside of gluster was its lack of flexibility, in particular the<br>
fact that there is no usage scaling factor on bricks, so that even with a<br>
simple distributed setup all your bricks have to be the same size. Also,<br>
the object store feature which I wanted to use, has clearly had hardly any<br>
testing (even the RPM packages don't install properly).<br>
<br>
I *really* wanted to deploy gluster, because in principle I like the idea of<br>
a virtual distribution/replication system which sits on top of existing<br>
local filesystems. But for storage, I need something where operational<br>
supportability is at the top of the pile.<br>
<br>
Regards,<br>
<br>
Brian.<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>With best regards,<br>differentlocal (<a href="http://www.differentlocal.ru">www.differentlocal.ru</a> | <a href="mailto:differentlocal@gmail.com">differentlocal@gmail.com</a>),<br>
System administrator.
</div>