[Top] [All Lists]

Re: raid10n2/xfs setup guidance on write-cache/barrier

To: xfs@xxxxxxxxxxx
Subject: Re: raid10n2/xfs setup guidance on write-cache/barrier
From: Martin Steigerwald <Martin@xxxxxxxxxxxx>
Date: Fri, 23 Mar 2012 23:48:08 +0100
In-reply-to: <20331.39194.377610.888636@xxxxxxxxxxxxxxxxxx>
References: <CAA8mOyDKrWg0QUEHxcD4ocXXD42nJu0TG+sXjC4j2RsigHTcmw@xxxxxxxxxxxxxx> <4F6624A3.5010206@xxxxxxxxxxxxxxxxx> <20331.39194.377610.888636@xxxxxxxxxxxxxxxxxx> (sfid-20120322_230623_659246_32AB6D3E)
User-agent: KMail/1.13.7 (Linux/3.2.0-2-amd64; KDE/4.7.4; x86_64; ; )
Am Donnerstag, 22. März 2012 schrieb Peter Grandi:
> Overselling 'delaylog' with cheeky propaganda glossing over the
> heavy tradeoffs involved is understandable, but quite wrong.

Thing is, as far as I understand Dave´s slides and recent entries in 
Kernelnewbies Linux Changes as well as Heise Open Kernel log is that - 
beside delaylog - there has been quite some other metadata related 
performance improvements.

Thus IMHO reducing the recent improvements in metadata performance is 
underselling XFS and overselling delaylog. Unless of course all those 
recent performance improvements could not have been done without the 
delaylog mode.

That said, this is just my interpretation. If all recent improvements are 
only due to delaylog, then I am obviously off track.

Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

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