From: Nuno Silva <nuno.silva@vgertech.com>
To: Eyal Lebedinsky <eyal@eyal.emu.id.au>
Cc: list linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: RAID resync speed
Date: Sat, 10 Sep 2005 05:54:25 +0100 [thread overview]
Message-ID: <43226701.1000606@vgertech.com> (raw)
In-Reply-To: <4322506A.1010303@eyal.emu.id.au>
Eyal Lebedinsky wrote:
> Nuno Silva wrote:
>>Hi,
>>Eyal Lebedinsky wrote:
>>>I noticed that my 3-disk RAID was syncing at about 40MB/s, now that I
>>>added a fourth disk it goes at only 20+MB/s. This is on an idle machine.
>>3*40=120
>>4*20=80
> What does this mean? The raid is syncing at 20MB/s, not each disk, so I do
> not see what the multiplication is about.
Yes, you're correct :-)
>>>Individually, each disk measures 60+MB/s with hdparm.
>>And concurrent hdparms? Or some dd's concurrently?
>
> I do not see this as relevant, but four concurrent hdparms (each to a
> different disk) give about 30MB/s per disk. I expect the controller
> to talk to the four disks at their full speed so concurrency should
> not be the issue.
I guess you're using linux's software raid?
If so, you're hitting the 120MB/sec (and I *think* this time I'm
correct! :-)
If this is a PCI32/33mhz slot you're not going to be able to get more
juice. (I bet that 3 concurrent dd's gets you 40MB each).
Anyway, this may be offtopic because the problem (only 20MB/sec for the
raid with 4 disks) should be something else... Sorry for the noise.
>>>kernel: 2.6.13 on ia32
>>>Controller: Promise SATAII150 TX4
>>>Disks: WD 320GB SATA
>>>
>>>Q: Is this the way the raid code works? The way the disk-io is
>>>managed? Or
>>>could it be due to the SATA controller?
>>
>>You can isolate the performance drop with some dd's. Maybe this card is
>>in a pci32/33mhz and you're hitting the pci bus' limits? (120~130MB/sec).
>
>
> 'hdparm -T' gives about 1250 MB/sec so this is not the limiting
> factor.
Mine outputs some fabulous values too... I'm not sure I trust them ;)
# hdparm -T /dev/sda
/dev/sda:
Timing cached reads: 3536 MB in 2.00 seconds = 1767.38 MB/sec
Regards,
Nuno Silva
next prev parent reply other threads:[~2005-09-10 4:54 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-10 2:11 RAID resync speed Eyal Lebedinsky
2005-09-10 2:53 ` Nuno Silva
2005-09-10 3:18 ` Eyal Lebedinsky
2005-09-10 4:54 ` Nuno Silva [this message]
2005-09-10 5:16 ` Joel Jaeggli
2005-09-11 2:16 ` Eyal Lebedinsky
2005-09-12 15:57 ` Roger Heflin
-- strict thread matches above, loose matches on Subject: below --
2014-03-20 1:12 raid " Jeff Allison
2014-03-20 14:35 ` Stan Hoeppner
2014-03-20 15:35 ` Bernd Schubert
2014-03-20 15:36 ` Bernd Schubert
2014-03-20 16:19 ` Eivind Sarto
2014-03-20 16:22 ` Bernd Schubert
2014-03-20 18:44 ` Stan Hoeppner
2014-03-27 16:08 ` Bernd Schubert
2014-03-28 8:03 ` Stan Hoeppner
2014-03-20 17:46 ` Bernd Schubert
2014-03-21 0:44 ` Jeff Allison
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=43226701.1000606@vgertech.com \
--to=nuno.silva@vgertech.com \
--cc=eyal@eyal.emu.id.au \
--cc=linux-kernel@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.