observed significant performance improvement using "delaylog" in
Quoted 9 lines
I'm pleased to state that using the experimental "delaylog" mount option (in vanilla linux-2.6.35) we measured a 17% performance increase for our benchmark scenario. (Other mount-options in use both before and after the "delaylog" option: noatime,nodiratime,nobarrier)
That's a lot given that XFS was the fastest performing file-system for this application already.
So thanks to all contributing developers for this significant optimization!
I did a benchmark (a simple copy/untar not something fancy) some time ago and also noticed great improvement.
Here is my post with the results of the benchmark.
http://lordkhelben.wordpress.com/2010/07/08/xfs-delayed-logging/
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 2 lines · On Donnerstag, 12. August 2010 Khelben Blackstaff wrote:
Here is my post with the results of the benchmark.
http://lordkhelben.wordpress.com/2010/07/08/xfs-delayed-logging/
Wow, BTRFS rocks. I guess I'll use it once it's released. But I'm stunned that XFS is that much slower than ext4 in many tests.
Signature · 13 lines
mit freundlichen Grüssen, Michael Monnerie, Ing. BSc it-management Internet Services http://proteger.at [gesprochen: Prot-e-schee] Tel: 0660 / 415 65 31 ****** Aktuelles Radiointerview! ****** http://www.it-podcast.at/aktuelle-sendung.html // Wir haben im Moment zwei Häuser zu verkaufen: // http://zmi.at/langegg/ // http://zmi.at/haus2009/
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 5 lines · Michael Monnerie
Quoted 2 lines · On Donnerstag, 12. August 2010 Khelben Blackstaff wrote:
Here is my post with the results of the benchmark.
http://lordkhelben.wordpress.com/2010/07/08/xfs-delayed-logging/Wow, BTRFS rocks.
Be sure to measure your specific use-case before jumping to conclusions.
With our application, for example, Btrfs performed exceptionally bad - about 4 times(!) as slow as XFS.
Then again, there are some use-cases where even older file-systems like reiser3 excel (e.g. storing files for cyrus imapd).
Quoted 1 line
But I'm stunned that XFS is that much slower than ext4 in many tests.
Again, it all depends on the use-case. For us, ext4 performs good (when used with all kinds of performance-enhancing, safety-reducing mount-options), but not as good as XFS.
To me, as of today, XFS' big strength is performing good to excellent (while not always better than all other file-systems) in many use-cases - without worries about instability or immaturity.
One thing, I guess, is for sure: Every file-system will require continued development to stay competitive.
SSDs, for example, are just beginning to get used appropriately by modern file-systems. There's plenty of opportunity left to optimize for them.
And once that is done, there may be yet another storage-technology available (PRAM? Racetrack?), that benefits from specific strategies.
So the competition will stay open... :-)
Regards,
Peter Niemayer
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Peter Niemayer put forth on 8/12/2010 4:46 PM:
Quoted 3 lines
To me, as of today, XFS' big strength is performing good to excellent (while not always better than all other file-systems) in many use-cases - without worries about instability or immaturity.
+1 But don't forget the excellent tool set which I think is a little better than those of the other filesystems. XFS has the only functional/reliable online defrag tool AFAIK. The only 'missing' feature compared to the other FSes is filesystem shrink ability, but for the majority of XFS users, I'm guessing this isn't an issue as data sets are always growing.
Some benchmark results maybe worth a look:
http://btrfs.boxacle.net/repository/raid/2.6.35-rc5/2.6.35-rc5/
Signature · 6 lines
Stan _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 2 lines · On Freitag, 13. August 2010 Stan Hoeppner wrote:
Some benchmark results maybe worth a look:
http://btrfs.boxacle.net/repository/raid/2.6.35-rc5/2.6.35-rc5/
Thanks - it would have been great to see xfs with delaylog in that comparison, but the graphs are very very nice.
XFS seems performing better the more threads there are, just in "large file random reads" it's the slowest - why this?
A test with "lots of small files in a dir" would be great, something like the squid cachedir or just a single dir with >5.000 files in it.
Signature · 13 lines
mit freundlichen Grüssen, Michael Monnerie, Ing. BSc it-management Internet Services http://proteger.at [gesprochen: Prot-e-schee] Tel: 0660 / 415 65 31 ****** Aktuelles Radiointerview! ****** http://www.it-podcast.at/aktuelle-sendung.html // Wir haben im Moment zwei Häuser zu verkaufen: // http://zmi.at/langegg/ // http://zmi.at/haus2009/
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 9 lines · Michael Monnerie
Quoted 2 lines · On Freitag, 13. August 2010 Stan Hoeppner wrote:
Some benchmark results maybe worth a look:
http://btrfs.boxacle.net/repository/raid/2.6.35-rc5/2.6.35-rc5/Thanks - it would have been great to see xfs with delaylog in that comparison, but the graphs are very very nice.
XFS seems performing better the more threads there are, just in "large file random reads" it's the slowest - why this?
Any idea who is doing these runs? Once we figure out what that large file random reads loads is I'm sure we could fix it soon. And asking him/her to add -o delaylog would also be good.
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 5 lines · Christoph Hellwig
Quoted 4 lines · Michael Monnerie
Quoted 2 lines · On Freitag, 13. August 2010 Stan Hoeppner wrote:
Some benchmark results maybe worth a look:
http://btrfs.boxacle.net/repository/raid/2.6.35-rc5/2.6.35-rc5/
Quoted 7 lines
Quoted 5 lines
Thanks - it would have been great to see xfs with delaylog in that comparison, but the graphs are very very nice.
XFS seems performing better the more threads there are, just in "large file random reads" it's the slowest - why this?
Any idea who is doing these runs?
IIRC the tests are run by someone from IBM, but I cannot remember who it is.
Quoted 4 lines
Once we figure out what that large
file random reads loads is I'm sure we could fix it soon.
Random Reads (raid, single-disk)
Start with 1024 files.
100 MB files on the raid system.
35 MB files on the single-disk system.
Each thread reads a fixed amount of data from a random location in one file using 4 kB reads.
5 MB reads on the raid system.
1 MB reads on the single-disk system.
So it's not a small random read workload (100GB data set), so the files on XFS are probably more spread out over multiple AGs and hence further apart than other filesystems. Hence a greater average seek distance, hence it slower throughput....
Quoted 2 lines
And asking
him/her to add -o delaylog would also be good.
Yes, that would be an interesting comparison...
Cheers,
Dave.
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 1 line · Dave Chinner
On Fri, Aug 13, 2010 at 08:29:07AM -0400, Christoph Hellwig wrote:
...
Quoted 4 lines
Quoted 2 lines
And asking
him/her to add -o delaylog would also be good.Yes, that would be an interesting comparison...
I was thinking the same thing; I'll do that.
-Eric
Quoted 4 lines
Cheers,
Dave.
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Hi!
Cc'd Steve as I think he is running the benchmarks.
Am Freitag 13 August 2010 schrieb Eric Sandeen:
Quoted 10 lines
Quoted 1 line · Dave Chinner
On Fri, Aug 13, 2010 at 08:29:07AM -0400, Christoph Hellwig wrote:
...
Quoted 4 lines
Quoted 2 lines
And asking
him/her to add -o delaylog would also be good.Yes, that would be an interesting comparison...
I was thinking the same thing; I'll do that.
I think its Steven Pratt from IBM.
Steve, could you add a case for mount option "-o delaylog" to your benchmark runs?
---------- Weitergeleitete Nachricht ----------
Subject: New performance results
Date: Samstag 24 April 2010
From: Steven Pratt <[email protected]>
To: "linux-btrfs" <[email protected]>
Well, it's been a while but been very busy on other things. Thanks to Keith Mannthey for helping get some of these runs done.
New raid performance on 2.6.34-rc3:
http://btrfs.boxacle.net/repository/raid/2010-04-14_2004/2.6.34-
rc3/2.6.34-rc3.html
Also, the long running history graphs are here:
http://btrfs.boxacle.net/repository/raid/history/History.html
Steve
--
[...]
-------------------------------------------------------
Ciao,
Signature · 7 lines
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 16 lines · Martin Steigerwald
Hi!
Cc'd Steve as I think he is running the benchmarks.
Am Freitag 13 August 2010 schrieb Eric Sandeen:
Quoted 10 lines
Quoted 2 lines · Dave Chinner
On Fri, Aug 13, 2010 at 08:29:07AM -0400, Christoph Hellwig wrote:
...
Quoted 3 lines
Quoted 3 lines
And asking
him/her to add -o delaylog would also be good.
Quoted 9 lines
Quoted 4 lines
Quoted 2 lines
Yes, that would be an interesting comparison...
I was thinking the same thing; I'll do that.
I think its Steven Pratt from IBM.
Steve, could you add a case for mount option "-o delaylog" to your benchmark runs?
Which filesystem is this for? Keith has been helping me with some of these runs. We'll see if we can add this.
Steve
Quoted 19 lines
---------- Weitergeleitete Nachricht ----------
Subject: New performance results
Date: Samstag 24 April 2010
From: Steven Pratt <[email protected]>
To: "linux-btrfs" <[email protected]>Well, it's been a while but been very busy on other things. Thanks to Keith Mannthey for helping get some of these runs done.
New raid performance on 2.6.34-rc3:
http://btrfs.boxacle.net/repository/raid/2010-04-14_2004/2.6.34-
rc3/2.6.34-rc3.htmlAlso, the long running history graphs are here:
http://btrfs.boxacle.net/repository/raid/history/History.html
Quoted 9 lines
Steve
--
[...]
-------------------------------------------------------Ciao,
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 13 lines · Steven Pratt
Quoted 12 lines · Martin Steigerwald
Hi!
Cc'd Steve as I think he is running the benchmarks.
Am Freitag 13 August 2010 schrieb Eric Sandeen:
Quoted 7 lines
Quoted 1 line · Dave Chinner
On Fri, Aug 13, 2010 at 08:29:07AM -0400, Christoph Hellwig wrote:
...
Quoted 3 lines
Quoted 2 lines
And asking
him/her to add -o delaylog would also be good.Yes, that would be an interesting comparison...
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
I was thinking the same thing; I'll do that.
I think its Steven Pratt from IBM.
Steve, could you add a case for mount option "-o delaylog" to your benchmark runs?
Which filesystem is this for? Keith has been helping me with some of these runs. We'll see if we can add this.
XFS - it's a new mount option for 2.6.35. Gory details in Documentation/filesystems/xfs-delayed-logging-design.txt.
Cheers,
Dave.
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs