From: Thomas Kaehn <tk@westend.com>
To: Justin Piszcz <jpiszcz@lucidpixels.com>
Cc: xfs@oss.sgi.com
Subject: Re: Strange delete performance using XFS
Date: Wed, 4 Apr 2007 16:35:33 +0200 [thread overview]
Message-ID: <20070404143533.GF12481@mail3b.westend.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0704041023570.7309@p34.internal.lan>
Hi Justin,
On Wed, Apr 04, 2007 at 10:24:42AM -0400, Justin Piszcz wrote:
> >On Wed, Apr 04, 2007 at 10:12:48AM -0400, Justin Piszcz wrote:
> >>On Wed, 4 Apr 2007, Justin Piszcz wrote:
> >>>On Wed, 4 Apr 2007, Thomas Kaehn wrote:
> >>>$ time for i in `seq 1 100000`; do dd if=/dev/zero of=$i bs=1k count=20
> >>>>/dev/null 2>&1; done
> >>>
> My guess is mkfs.xfs cannot optimzie for your array like it can with a SW
> RAID device because it cannot see what is undereath it. Have you tried
> making a SW RAID? I also use optimized parameters for my SW RAID1/5 as
> well FYI.
I guess this might be the problem. I've already tried to alter
the stripe unit to match the RAID stripe size: "-d su=64k,sw=2 -l su=64k".
Maybe the 3ware controller can't deal with the kind of read and write
patterns needed by XFS. But in this case other people should have
realized similar problems.
On a different system with a 3ware 9500S-4LP using 4 disks as RAID5
setup I get a better (but not really good) result for delete
performance (I've taken only 50000 files in this case as the system's
CPU is much slower):
| # time for i in `seq 1 50000`; do dd if=/dev/zero of=$i
| bs=1k count=20 >/dev/null 2>&1; done
|
| real 18m21.643s
| user 0m55.727s
| sys 3m12.140s
| backup:/srv/x# cd ..
| backup:/srv# rm -rf x
|
| # time rm -rf x
|
| real 5m7.845s
| user 0m0.160s
| sys 0m11.369s
Ciao,
Thomas
--
Thomas Kähn WESTEND GmbH | Internet-Business-Provider
Technik CISCO Systems Partner - Authorized Reseller
Im Süsterfeld 6 Tel 0241/701333-18
tk@westend.com D-52072 Aachen Fax 0241/911879
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Die Gesellschaft ist eingetragen im Handelsregister Aachen unter HRB 7608
Geschäftsführer: Thomas Neugebauer, Thomas Heller, Michael Kolb
next prev parent reply other threads:[~2007-04-04 14:35 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-04 13:05 Strange delete performance using XFS Thomas Kaehn
2007-04-04 13:29 ` Justin Piszcz
2007-04-04 13:47 ` Thomas Kaehn
2007-04-04 13:51 ` Justin Piszcz
2007-04-04 13:57 ` Justin Piszcz
2007-04-04 13:57 ` Justin Piszcz
2007-04-04 14:12 ` Justin Piszcz
2007-04-04 14:21 ` Thomas Kaehn
2007-04-04 14:24 ` Justin Piszcz
2007-04-04 14:35 ` Thomas Kaehn [this message]
2007-04-04 20:45 ` Justin Piszcz
2007-04-04 14:13 ` Justin Piszcz
2007-04-05 8:17 ` Thomas Kaehn
2007-04-04 18:36 ` Justin Piszcz
2007-04-05 7:37 ` Thomas Kaehn
2007-04-04 15:45 ` Chris Wedgwood
2007-04-05 7:28 ` Thomas Kaehn
2007-04-05 9:03 ` Thomas Kaehn
2007-04-05 10:21 ` Justin Piszcz
2007-04-05 10:50 ` Thomas Kaehn
2007-04-05 11:11 ` Justin Piszcz
2007-04-05 15:29 ` Chris Wedgwood
2007-04-06 19:02 ` Peter Grandi
2007-04-11 9:36 ` Thomas Kaehn
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=20070404143533.GF12481@mail3b.westend.com \
--to=tk@westend.com \
--cc=jpiszcz@lucidpixels.com \
--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