public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Martin Steigerwald <Martin@lichtvoll.de>
To: xfs@oss.sgi.com
Subject: Re: Extreme slowness with xfs [WAS: Re: Slowness with new pc]
Date: Wed, 26 Nov 2008 13:30:26 +0100	[thread overview]
Message-ID: <200811261330.27328.Martin@lichtvoll.de> (raw)
In-Reply-To: <1227647010.7992.34.camel@chevrolet>

Am Dienstag 25 November 2008 schrieb Stian Jordet:
> ma., 24.11.2008 kl. 19.36 -0600, skrev Eric Sandeen:
> > I don't know if the storage you're on passes barriers or not, but xfs
> > has barriers on by default, while ext3 does not.  ext3 will still
> > likely
> > win the "untar a kernel" race, but for a fairer test, make the
> > barrier settings consistent between the two.
>
> As I wrote earlier, the point wasn't to find the fastest fs. That's not
> what I'm looking for. I just want xfs to perform at least as good on my
> new workstation as it did on my six years old other workstation.
>
> Which disabling barriers helped (notice the rm -rf with barriers...
> nobarrier is almost 200 times faster, 10 times faster on the
> unpacking):

[...]

> ### Ext3
>
> time bash -c 'tar xjf linux-2.6.27.7.tar.bz2 ; sync'
>
> real 0m18.663s
> user 0m14.693s
> sys 0m2.828s
>
>
> time bash -c 'rm -r linux-2.6.27.7 ; sync'
> real 0m0.635s
> user 0m0.028s
> sys 0m0.564s

It would be interesting to know the value on Ext3 with barriers.

I wonder whether XFS performance with barriers enabled can be improved? 
And whether XFS with disabled write cache (via hdparm) but without 
barriers might even be *faster* than XFS with barriers... One thing to 
test eventually.

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

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  parent reply	other threads:[~2008-11-26 12:31 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1226760254.5089.11.camel@chevrolet>
     [not found] ` <430c4fa50811180551r67d5d680tf1ffa493604ac4ea@mail.gmail.com>
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
     [not found]                   ` <1227649893.6557.10.camel@oldsmobile>
2008-11-25 22:02                     ` David Sparks
2008-11-25 22:31                       ` Stian Jordet
2008-11-25  1:36             ` Eric Sandeen
     [not found]               ` <1227647010.7992.34.camel@chevrolet>
2008-11-26 12:30                 ` Martin Steigerwald [this message]
2008-11-26 21:43                   ` Dave Chinner

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=200811261330.27328.Martin@lichtvoll.de \
    --to=martin@lichtvoll.de \
    --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