On Tue, Aug 10, 2010 at 06:01:33PM +0200, Peter Niemayer wrote: > Hi all, > > we use XFS for a very I/O-intensive, in-house developed real-time > database application, and whenever we see new or significantly > changed file-systems becoming available, we run a benchmark using > this application on a conserved, fixed real-world data set. > > 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 great to hear. One thing that you might want to try to further improve performance is the logbsize=262144 option as well. That will help flush log IO faster by doing less IOs. Also, if your workload is doing lots of fsync calls, then the optimisations I posted a few days ago should also help improve delaylog throughput. > That's a lot given that XFS was the fastest performing file-system > for this application already. > > It's also a promising result regarding stability, as several other > tests (using e.g. reiser4 or ceph) in the past led to crashes in the > same benchmark scenario. That's definitely encouraging. ;) > So thanks to all contributing developers for this significant optimization! And thanks for the feedback. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs