<div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">From: Joe Landman &lt;<a href="mailto:landman@scalableinformatics.com" target="_blank">landman@scalableinformatics.com</a>&gt; </blockquote>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That&#39;s not the issue with glusterfs.  It&#39;s distributed metadata architecture is a double edged sword.  Very good for distributed data, very very bad for metadata heavy ops.<br>
<br>
That and the xfs attributes haven&#39;t been slow in years though some folks like bringing up the old behavior pre 2.6.26 as examples of why you shouldn&#39;t use it.   Dave Chinner has a great presentation on the topic from 15 months ago or so.  Puts down real numbers.  Situation is rather different than implied.<br>
<br></blockquote><div><br></div><div>We&#39;ve recently seen XFS kill a pretty important server after an abrupt power off.  It appears someone decided they needed to force it to be &quot;POSIX&quot; compliant by default, and as a result XFS doesn&#39;t sync/flush to disk unless told to or some rather long timeout (30 seconds can be verrry long ).  </div>
<div><br></div><div>Has anyone else seen this / been surprised / re-tuned / written the how-to for me?</div><div><br></div><div>If you tune it you can get it back to it&#39;s good old days... flushing routinely.... but we haven&#39;t messed with it much since.  XFS, RIP...  at least for until we need it again :)</div>
<div><br></div><div>GlusterFS... my jury is still out.  I tried it once with some viscous metadata munging code and Joe told me never to do that to Gluster again I think.  The code was abusive honestly, nearly evil.</div>
<div><br></div><div>Cheers!</div><div>Greg</div><div><br></div><div>&quot;Joe Landman, now there&#39;s a frood who knows where his towel is!&quot;</div></div></div>