RE: RAID resync speed

["Roger Heflin" <rheflin@atipa.com>]

> 
> 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/