[Top] [All Lists]

Re: xfs performance problem

To: xfs@xxxxxxxxxxx
Subject: Re: xfs performance problem
From: Michael Monnerie <michael.monnerie@xxxxxxxxxxxxxxxxxxx>
Date: Sat, 30 Apr 2011 22:36:39 +0200
In-reply-to: <19898.53907.842827.480883@xxxxxxxxxxxxxxxxxx>
Organization: it-management http://it-management.at
References: <4DB72084.8020205@xxxxxxxxxxx> <4DB75C6D.1080901@xxxxxxxxxxx> <19898.53907.842827.480883@xxxxxxxxxxxxxxxxxx>
User-agent: KMail/1.13.6 (Linux/; KDE/4.6.0; x86_64; ; )
On Freitag, 29. April 2011 Peter Grandi wrote:
> Despite decades of seeing it happen, I keep being astonished by
> how many people (some with decades of "experience") just don't
> understand IOPS and metadata and commits and caching and who
> think "performance" is whatever number they can get with their
> clever "benchmarks".

Although I understand your arguing, the OP just said that with ext3 the 
process returns after 22s, while on xfs he has to wait 2m20s to have the 
command prompt back.

That's not a benchmark, but user experience. I'm also surprised by that 
big difference, and given the numbers are correct I would say ext3 does 
something "better" here than xfs. I'd guess it's only an effect of 
caching, and in thruth the disks are still running like crazy in the 
background. But hey, if I decompress a kernel I'm more happy if it 
returns after 22s and I can start "make menuconfig", than having to wait 
2m20s. The damn thing should write in the background, that doesn't hurt 
(in this specific case).

mit freundlichen Grüssen,
Michael Monnerie, Ing. BSc

it-management Internet Services: Protéger
http://proteger.at [gesprochen: Prot-e-schee]
Tel: +43 660 / 415 6531

// ****** Radiointerview zum Thema Spam ******
// http://www.it-podcast.at/archiv.html#podcast-100716
// Haus zu verkaufen: http://zmi.at/langegg/

Attachment: signature.asc
Description: This is a digitally signed message part.

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