Yes. WRITE_SYNC should be good. Not FUA.<div><br></div><div>Also, you may want to look into using io priorities. The code is all there. Just needs activation.<br><br><div class="gmail_quote">On Wed, Aug 22, 2012 at 10:13 AM, srinivas eeda <span dir="ltr"><<a href="mailto:srinivas.eeda@oracle.com" target="_blank">srinivas.eeda@oracle.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div class="im">
<br>
On 8/22/2012 7:17 AM, Jie Liu wrote:
<blockquote type="cite">
Hi All,<br>
<br>
These days, I am investigating an issue regarding OCFS2 unexpected
reboot in some real world use cases.<br>
This problem occurred when the network status goes south, when the
disk IO load is too high, etc...<br>
I suspect it might caused by ocfs2 fencing if it's BIO
reading/writing can not be scheduled and processed quickly, or<br>
something like this happened in the network IO heartbeat thread.<br>
<br>
Now am trying to reproduce this problem locally. In the meantime,
I'd like to ping you guys with some rough ideas<br>
to improve the disk IO heartbeat to see if they are sounds
reasonable or not.<br>
<br>
Firstly, if an OCFS2 node is suffer from heavy disk IO, how about
to fix the bio read/write to make this IO request can not<br>
be preempted by other requests? e.g, for <span style="margin-right:0"><span></span></span>o2hb_issue_node_write(),
currently, it do bio submission with WRITE only,<br>
'submit_bio(WRITE, bio)'. If we change the flag to WRITE_SYNC,
or even submit the request combine with REQ_FUA,<br>
maybe could get highest priority for disk IO request.<br>
</blockquote></div>
This was submitted before by Noboru Iwamatsu and acked by sunil and
tao but some how didn't get merged<br>
<br>
<a href="https://oss.oracle.com/pipermail/ocfs2-devel/2011-December/008438.html" target="_blank">https://oss.oracle.com/pipermail/ocfs2-devel/2011-December/008438.html</a><br>
<blockquote type="cite"><div class="im"> <br>
Secondly, the comments for bio allocation at o2hb_setup_one_bio()
indicates that we can pre-allocate bio instead of<br>
acquire for each time. But I have not saw any code snippet doing
such things in kernel. :(<br>
how about creating a private bio set for each o2hb_region, so that
we can do allocation out of it? <br>
maybe it's faster than do allocation from global bio sets. Also,
does it make sense if creating a memory pool<br>
on each o2hb_region, so that we can have continuous pages bind to
those bios?<br>
<br>
<br>
Any comments are appreciated!<br>
<br>
Thanks,<br>
-Jeff<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<fieldset></fieldset>
<br>
</div><pre>_______________________________________________
Ocfs2-devel mailing list
<a href="mailto:Ocfs2-devel@oss.oracle.com" target="_blank">Ocfs2-devel@oss.oracle.com</a>
<a href="https://oss.oracle.com/mailman/listinfo/ocfs2-devel" target="_blank">https://oss.oracle.com/mailman/listinfo/ocfs2-devel</a></pre>
</blockquote>
</div>
<br>_______________________________________________<br>
Ocfs2-devel mailing list<br>
<a href="mailto:Ocfs2-devel@oss.oracle.com">Ocfs2-devel@oss.oracle.com</a><br>
<a href="https://oss.oracle.com/mailman/listinfo/ocfs2-devel" target="_blank">https://oss.oracle.com/mailman/listinfo/ocfs2-devel</a><br></blockquote></div><br></div>