<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 31 March 2016 at 04:17, Eric Ren <span dir="ltr"><<a href="mailto:zren@suse.com" target="_blank">zren@suse.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi,<span class=""><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">How did you perform the testing? It really matters. If you write a file on<br>
shared disk from one node, and read this file from another node, without,<br>
or with very little interval, the writing IO speed could decrease by ~20<br>
times according my previous testing(just as a reference). It's a extremely<br>
bad situation for 2 nodes cluster, isn't?<br>
<br>
But it's incredible that in your case writing speed drop by >3000 times!<br>
</blockquote>
<br>
<br>
I simply used 'dd' to create a file with /dev/zero as a source. If there is<br>
a better way to do this I am all ears.<br>
</blockquote>
<br></span>
Alright, you just did a local IO on ocfs2, then the performance shouldn't be that bad. I guess the ocfs2 volume has been used over 60%? or seriously fragmented?<br>
Please give info with `df -h`, and super block with debugfs.ocfs2, and also the exact `dd` command you performed. Additionally, perform `dd` on each node.<br>
<br>
You know, ocfs2 is a shared disk fs. So 3 basic testing cases I can think of are:<br>
1. only one node of cluster do IO;<br>
2. more than one nodes of cluster perform IO, but each nodes just read/write its own file on shared disk;<br>
3. like 2), but some nodes read and some write a same file on shared disk.<br>
<br>
The above model is much theoretically simplified though. The practical scenarios could be much more complicated, like fragmentation issue that your case much likely is.</blockquote><div><br></div><div>Here is all the output requested: <a href="http://pastebin.com/raw/BnJAQv9T">http://pastebin.com/raw/BnJAQv9T</a></div><div><br></div><div>It's interesting to me that you guessed the usage is over 60%. It is indeed sitting at 65%. Is the solution as simple as ensuring that an OCFS2 filesystem doesn't go over the 60% usage mark? Or am I getting ahead of myself a little?</div><div><br></div><div>Thanks for your effort so far!</div><div><br></div><div>Graeme.</div></div></div></div>