mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Roger Heflin" <rheflin@atipa.com>
To: "'Eyal Lebedinsky'" <eyal@eyal.emu.id.au>,
	"'Nuno Silva'" <nuno.silva@vgertech.com>
Cc: "'list linux-kernel'" <linux-kernel@vger.kernel.org>
Subject: RE: RAID resync speed
Date: Mon, 12 Sep 2005 10:57:55 -0500	[thread overview]
Message-ID: <EXCHG2003WpSWerOc0N000006b6@EXCHG2003.microtech-ks.com> (raw)
In-Reply-To: <43239374.8010604@eyal.emu.id.au>

 

> 
> Actually, I took another look at this matter and I now think 
> that you had the correct approach.
> 
> The rebuild speed is the speed at which the new disk is being 
> built, not the total rebuild i/o. This means that it does not 
> contain the read operations. So the PCI limit is a limiting 
> factor. On a 32-bit 33MHz PCI controller (132MB/s theoretical 
> bandwidth) a 2->3 rebuild cannot be faster 44MB/s and a 3->4 
> is limited to 33MB/s.
> 
> I think this is true.
> 
> The same limit will also apply to any raid i/o as we 
> read/write to all the disks for any data.
> 
> To use 5 60MB/s disks I will need 300MB/s bandwidth which a 
> 64-bit 66MHz PCI can deliver. A 32-bit/66MHz will come close 
> - what can PCIe do?.
> A proper RAID card will alleviate the PCI limitation as it 
> will have dedicated channels for each disk (well, a good 
> controller should) with full bandwidth and the PCI will only 
> need to go at the one-disk speed (for raid-5).

You will need to carefully check the real raid controllers 
as some have separate channels some do not, it is all very 
much a mess, and you need to be very careful in checking
them and very careful in testing them if you need
real speed.

> 
> On-board SATA controllers will have better bandwidth if they 
> sit on a better than PCI bus (or on more than one PCI bus).

The all of on-board SATA controllers I have used have lots 
of shared hardware and are very very bad if you use more
than 1 disk per set of shared hardware, and  build in does
not mean that they will have a better PCI connection than
a card, it all depends on the sata chipset that they used,
there is stuff build into motherboards with pcix slots that
have the ide, sata, and network subsystems connected to 
33mhz buses.

Most of the stuff I have used is high end dual and quad
cpu motherboards, and the build in stuff does have lots
of corners cut, I would expect the desktop class stuff
to be as bad or worse.

                    Roger


      reply	other threads:[~2005-09-12 15:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-10  2:11 Eyal Lebedinsky
2005-09-10  2:53 ` Nuno Silva
2005-09-10  3:18   ` Eyal Lebedinsky
2005-09-10  4:54     ` Nuno Silva
2005-09-10  5:16       ` Joel Jaeggli
2005-09-11  2:16       ` Eyal Lebedinsky
2005-09-12 15:57         ` Roger Heflin [this message]

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=EXCHG2003WpSWerOc0N000006b6@EXCHG2003.microtech-ks.com \
    --to=rheflin@atipa.com \
    --cc=eyal@eyal.emu.id.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nuno.silva@vgertech.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

all inboxes | Powered by JetHome®