<div class="gmail_quote">On Wed, Feb 1, 2012 at 1:27 PM, Sunil Mushran <span dir="ltr"><<a href="mailto:sunil.mushran@oracle.com">sunil.mushran@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 class="im">On 02/01/2012 10:24 AM, Mark Hampton wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Here's what I got from debugfs.ocfs2 -R "stats". I have to type it out<br>
manually, so I'm only including the "features" lines:<br>
<br>
Feature Compat: 3 backup-super strict-journal-super<br>
Feature Incompat: 16208 sparse extended-slotmap inline-data metaecc<br>
xattr indexed-dirs refcount discontig-bg<br>
Feature RO compat: 7 unwritten usrquota grpquota<br>
<br>
<br>
Some other info that may be interesting:<br>
<br>
Links: 0 Clusters: 52428544<br>
</blockquote>
<br>
<br></div>
I would disable quotas. That line suggests the vol is 200G is size.<br>
</blockquote></div><br><div>Ok, I'll try disabling quotas and metaecc.<div><br></div><div>Yes, the filesystem is 200GB. This particular filesystem is 1 out of 16 OCFS2 filesystems. This is a 1/5 scale test of what will be in production.</div>
<div><br></div><div>I wonder if having 16 OCFS2 filesystems is ideal. 16 small OCFS2 filesystems definitely performed better than 1 large OFCS2 filesystem. Writing across 16 small OCFS2 filesystems turned out to be at least twice as fast. I don't know what the optimal number is though.</div>
<div><br></div><div>I noticed that there appear to be separate dlm process for each filesystem, so maybe reducing serialization is a factor in the improved performance?</div></div>