On Sun, May 01, 2011 at 08:24:42PM +0200, Markus Trippelsdorf wrote: > Another thing is that with the recent updates to block FLUSH handling, > using FUA might even be less efficient. The new implementation > aggressively merges those commit writes and flushes. IOW, depending > on timing, multiple consecutive commit writes can be merged as, > > FLUSH + commit writes + FLUSH > > or > > FLUSH + some commit writes + FLUSH + other commit writes + FLUSH > > and so on, Except that writing multiple log buffers right next to each other is rather unusual - you'd have to have a burst of metadata only operations to get there. What's more common is that a log write interrupts streams of actual data I/O, and the longer we drain the queue the more performance impact it has. Moreover I'm working on avoiding the pre-flush if it's not needed, e.g. there were no appending writes, and there as no pushing of the log tail required, in which case the log write will only be a write with FUA set, with no FLUSH and thus no queue draining on SATA at all. Also when you move away from SATA to higher latency links like FC or iSCSI (maybe even over a WAN) avoiding protocol roundtrips buys you a lot of performance. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
