<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 <<a href="mailto:landman@scalableinformatics.com" target="_blank">landman@scalableinformatics.com</a>> </blockquote>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That's not the issue with glusterfs.  It'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't been slow in years though some folks like bringing up the old behavior pre 2.6.26 as examples of why you shouldn'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'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 "POSIX" compliant by default, and as a result XFS doesn'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's good old days... flushing routinely.... but we haven'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>"Joe Landman, now there's a frood who knows where his towel is!"</div></div></div>