[ILUG] Booting a broken raid array
watty at eircom.net
Mon Jan 19 12:30:02 GMT 2009
Frank Peelo wrote:
> Niall O Broin wrote:
>> On 18 Jan 2009, at 07:03, paul at clubi.ie wrote:
>>> On Sun, 18 Jan 2009, Niall O Broin wrote:
>>>> ALL RAID is software - it's just a question of where the software
>>>> runs (and I include XOR engines here - still software, really,
>>>> just very specialised software, runing on very specialised hardware)
>>> Hmm, not that specialised. The Mylex ones were small embedded
>>> computers (i960 and then XScale) - using normal SIMMs/DIMMs even.
>>> Never seen any PERC cards, but no doubt similar thing
>> Read what I said Paul. The processors on 'hardware' RAID cards are
>> many and various - I've even seen x86 variants used IIRC. However, I
>> referred to the dedicated XOR hardware included on some cards to
>> offload these calculations from the card's CPU - the only thing
>> which coudl reasonably be called hardware RAID, as it wasn't
>> software executing on a general purpose CPU - though I'd still argue
>> that as it's executing an algorithm, it's software.
> A hardware design colleague let me in on a secret, it's all software.
> I use C, he uses VHDL, but it's all compiled text files :)
The theory of a CPU on the Controller card is that is reduces traffic on
the I/O bus.
The OS driver accesses controller card via (ISA originally, then MCA,
EISA or VESA) PCI bus as if a single Drive, or a collection of separate
drives and /or partitions as if a "dumb" SCSI port.
The I/O card controller then breaks cached data into N-1 chunks
for N drives that are RAID 5, calculates parity Chunk and then
using stripe algorithim writes each chunk to a separate drive. I/O
bandwidth is reduced on CPU bus and CPU overhead greatly diminished.
RAID 1 (Mirror) writes inherently ought to be twice as slow for bus I/O
done in SW compared with no RAID. A HW RAID Mirror (CPU on I/O card
doing SW) ought to mostly hide this from the host. RAID1 is of
course MUCH slower than RAID5 for multiple user I/O.
SCSI was always preferred as on same cable, several drives can be
seeking and other doing read/write. Other types of drive can't queue
like that then.
On a 486 the difference between Host SW RAID and Controller i960 based
"HW" RAID performance is dramatic.
I've compared Host SW
mirror boot + SW RAID 5 data using 4 x IDE drives, partitioned PM and SM
boot mirror and remaining part of all 4 PM, PS, SM, SS as 4 part RAID 5
and same SW with "dumb" SCSI and 2 x SCSI mirror and 3 x SCSI RAID5 of
similar speed. The SCSI system similar on single block transfer, but on
Multi-user access the IDE dropped to about 1/100th speed due to lack of
drive concurrency and Random Access. Little Drop in speed of SCSI.
This was P90s, Pentium Pro 200, AMD K6 200 systems and lastly a PIII
933MHz with RAMBUS memory.
An AMI i960 MegaRAID (aka earlier DELL PERC) made small SCSI speed
improvement but dramatically reduced host CPU % time and Memory overhead
on the PIII 933.
With the "HW" based approach (really SW on separate i960 RISC cpu),
rebuild is faster of failed drive and less impact on system performance.
Comparisons all on NT4.0 Enterprise edition as Linux SW RAID support
didn't work back then. Actually NTFS (SW RAID or not) copes FAR better
with ESB fail and no UPS than EXT2 on Clarkconnect. I had to put
UPS on my Clarkconnect box as it scrambled the dumb SCSI (no
RAID) on every power cut. Is EXT3 better at coping with "dirty"
filesystem / power fails?
Rebuild or even reboot of IDE based Host SW RAID1 + RAID 5 is a
total pain and SCSI based SW RAID a bit of pain compared with "HW"
AMI Megaraid based systems. There was a special version in 1998
or 1999 of AMI Megaraid 428 with reassign on host ID so the 2
channels used via external SCSI repeater/Auto Termination to two
external Drive shelves in RAID 10 daisy chain to second controller at
alt host ID on 2nd PC to implement early cheap cluster. (DEC SW before
MS Cluster SW came out). Worked very well. You could pull power on
either Drive shelf or either CPU with no loss of virtual servers or files.
More information about the ILUG