<br><br><div class="gmail_quote">On Tue, Nov 13, 2012 at 2:40 PM, Vincent Diepeveen <span dir="ltr"><<a href="mailto:diep@xs4all.nl" target="_blank">diep@xs4all.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Nov 13, 2012, at 9:17 PM, Greg Keller wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
From: Joe Landman <<a href="mailto:landman@scalableinformatics.com" target="_blank">landman@scalableinformatics.<u></u>com</a>>  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>
<br>
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 ).<br>

</blockquote>
<br>
You sure this is just XFS problem?<br>
<br>
Linux also has this behaviour towards floppy disk over here and that floppy disk doesn't have XFS.<br>
<br>
Maybe it's a kernel feature that assumes most people have a cheap WD disk?<br>
<br>
In fact to save the new generation harddisks from for example WD that could be interesting feature.<br>
<br>
I've read some reports that the cheap versions of them quite quickly go to power savings mode, though not sure how long it takes<br>
to reach that idle mode. Then it would spin up again when there is disk activity. Yet this flip between power saving and spinning active<br>
if i see some users report it, that can be done only a limited amount of time, which would normally spoken give the disk because of<br>
that an average lifetime of no more than a year or so in case your machine is writing regurarly something to disk.<br>
<br>
Maybe this feature of XFS helps a tad there? Or should it wait for 30 minutes then to write to disk?<br></blockquote><div><br></div><div>No, I was told this was a conscious decision to follow the POSIX spec exactly.  Maybe it helps not spin up drives and saves $0.07 cents per year... but I think that's collateral savings. </div>
<div><br></div><div>To Mr. Becker's Point, we used XFS for large filesystems for years with absolutely no trouble, on 100's of TB of storage.  It was years ahead of EXT4 in making big volumes simple too EXT# types.  </div>
<div><br></div><div>Whatever was changed recently (not sure when), I would use XFS, but only once I really understood the tuning/flushing and did some sudden power off and kernel crash testing.  If you're running a version from before the change it will probably work just like you think it should.</div>
<div><br></div><div>Cheers!</div><div>Greg</div></div>