xfs
[Top] [All Lists]

Re: 12x performance drop on md/linux+sw raid1 due to barriers [xfs]

To: Eric Sandeen <sandeen@xxxxxxxxxxx>, Martin Steigerwald <Martin@xxxxxxxxxxxx>, linux-xfs@xxxxxxxxxxx, Alan Piszcz <ap@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
Subject: Re: 12x performance drop on md/linux+sw raid1 due to barriers [xfs]
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Sun, 14 Dec 2008 17:55:30 -0600
In-reply-to: <20081214233617.GD32301@disturbed>
References: <alpine.DEB.1.10.0812060928030.14215@xxxxxxxxxxxxxxxx> <493A9BE7.3090001@xxxxxxxxxxx> <alpine.DEB.1.10.0812130724340.18746@xxxxxxxxxxxxxxxx> <200812131826.25280.Martin@xxxxxxxxxxxx> <4943F37B.8080405@xxxxxxxxxxx> <20081214233617.GD32301@disturbed>
User-agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
Dave Chinner wrote:
> On Sat, Dec 13, 2008 at 11:40:11AM -0600, Eric Sandeen wrote:
>> Martin Steigerwald wrote:
>>
>>> At the moment it appears to me that disabling write cache may often give 
>>> more performance than using barriers. And this doesn't match my 
>>> expectation of write barriers as a feature that enhances performance. 
>> Why do you have that expectation?  I've never seen barriers advertised
>> as enhancing performance.  :)
>>
>> I do wonder why barriers on, write cache off is so slow; I'd have
>> thought the barriers were a no-op.  Maybe I'm missing something.
> 
> Barriers still enforce ordering in this case, so it affects the
> elevator algorithm....

(taking linux-raid off becase at this point it really has nothing to do
with the thread).

oh, er, so is nobarrier+nowritecache safe or not?  If the elevator can
reorder for us (even though the drive won't) then a journaling fs which
needs these ordering guarantees may still be in trouble?

Just when I think I have it all straight... :)

(ok, so now nobarrier+nowritecache+noop io scheduler might be an
interesting test).

-Eric

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