Re: xfs performance problem

[Christoph Hellwig <hch@infradead.org>]

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@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs