From: Michael Tokarev <mjt@tls.msk.ru>
To: Justin Piszcz <jpiszcz@lucidpixels.com>
Cc: Eric Sandeen <sandeen@sandeen.net>,
Stian Jordet <liste@jordet.net>,
linux-kernel@vger.kernel.org, xfs@oss.sgi.com,
Alan Piszcz <ap@solarrain.com>
Subject: Re: Extreme slowness with xfs [WAS: Re: Slowness with new pc]
Date: Tue, 25 Nov 2008 21:39:38 +0300 [thread overview]
Message-ID: <492C466A.7070200@msgid.tls.msk.ru> (raw)
In-Reply-To: <alpine.DEB.1.10.0811250456010.16346@p34.internal.lan>
Justin Piszcz wrote:
[]
> barriers enabled:
> real 2m40.643s
> barriers disabled:
> real 0m27.612s
Barriers enabled:
$ time sh -c "tar xf linux-2.6.27.tar.bz2; sync"
real 2m3.317s
user 0m33.990s
sys 0m3.980s
$ time sh -c "rm -rf linux-2.6.27; sync"
real 1m4.033s
user 0m0.080s
sys 0m2.860s
Barriers disabled:
$ time sh -c "tar xf linux-2.6.27.tar.bz2; sync"
real 0m36.279s
user 0m25.610s
sys 0m2.800s
$ time sh -c "rm -rf linux-2.6.27; sync"
real 0m3.694s
user 0m0.010s
sys 0m2.230s
During unpack, with barriers=on, the cpu usage stays
hardy noticeable, while with barriers=off, the thing
becomes CPU-bound (needed for bzip2).
For comparison, here are results for jfs on the
same drive:
$ time sh -c "tar xf /stage/build/kernel/linux-2.6.27.tar.bz2; sync"
real 0m36.062s
user 0m25.370s
sys 0m2.860s
$ time sh -c "rm -rf linux-2.6.27; sync"
real 0m3.024s
user 0m0.040s
sys 0m0.750s
This jfs partition is located a bit further on the same disk,
so raw speed of it is a bit lower. Yet the numbers are pretty
similar. In any case, xfs with barriers is MUCH worse...
The disk is a 500Gig Hitachi HUA72105 one ("raid edition"),
on an AMD 780g/SB700 chipset in ahci mode.
/mjt
next prev parent reply other threads:[~2008-11-25 18:39 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-15 14:44 Slowness with new pc Stian Jordet
2008-11-18 13:51 ` Sergio Luis
2008-11-23 21:48 ` Extreme slowness with xfs [WAS: Re: Slowness with new pc] Stian Jordet
2008-11-23 22:25 ` Justin Piszcz
2008-11-24 0:19 ` Stian Jordet
2008-11-24 9:50 ` Justin Piszcz
2008-11-24 23:36 ` Stian Jordet
2008-11-24 23:52 ` Justin Piszcz
2008-11-25 0:09 ` Sven-Haegar Koch
2008-11-25 20:44 ` Stian Jordet
2008-11-25 21:22 ` Eric Sandeen
2008-11-25 21:51 ` Stian Jordet
2008-11-25 1:36 ` Eric Sandeen
2008-11-25 9:56 ` Justin Piszcz
2008-11-25 10:44 ` Christoph Hellwig
2008-11-25 10:46 ` Justin Piszcz
2008-11-25 18:39 ` Michael Tokarev [this message]
2008-11-25 21:03 ` Stian Jordet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=492C466A.7070200@msgid.tls.msk.ru \
--to=mjt@tls.msk.ru \
--cc=ap@solarrain.com \
--cc=jpiszcz@lucidpixels.com \
--cc=linux-kernel@vger.kernel.org \
--cc=liste@jordet.net \
--cc=sandeen@sandeen.net \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox