xfs
[Top] [All Lists]

Re: xfs performance problem

To: Markus Trippelsdorf <markus@xxxxxxxxxxxxxxx>
Subject: Re: xfs performance problem
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Mon, 2 May 2011 06:14:01 -0400
Cc: Dave Chinner <david@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <20110501182442.GA1635@xxxxxxxxxxxxxx>
References: <4DB72084.8020205@xxxxxxxxxxx> <20110427023534.GF12436@dastard> <201104291827.35801.Martin@xxxxxxxxxxxx> <20110501085246.GF13542@dastard> <20110501165546.GB5391@xxxxxxxxxxxxx> <20110501182442.GA1635@xxxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
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.

<Prev in Thread] Current Thread [Next in Thread>