Slightly off topic.....
Has anyone had any experience with getting these drivers into a "virgin" HP and then installing Redhat/Fedora? If so, can someone give me a clue - like which one will work? HP's site is not too obvious or straightforward....
TIA
WPH
On Thu, 2004-11-04 at 10:48 -0800, William Hewitt wrote:
Slightly off topic.....
Has anyone had any experience with getting these drivers into a "virgin" HP and then installing Redhat/Fedora? If so, can someone give me a clue - like which one will work? HP's site is not too obvious or straightforward....
you don't need drivers for this software raid; you can just use the dmraid software tool!
Arjan van de Ven wrote:
On Thu, 2004-11-04 at 10:48 -0800, William Hewitt wrote:
Slightly off topic.....
Has anyone had any experience with getting these drivers into a "virgin" HP and then installing Redhat/Fedora? If so, can someone give me a clue - like which one will work? HP's site is not too obvious or straightforward....
you don't need drivers for this software raid; you can just use the dmraid software tool!
Errr, you do if the Kernel does not even recognize the controller drives at all. (Which it does not with this esoteric controller.) And I am always amazed how people seems to think using software raid is as good a solution as using hardware raid. Come on, there is no comparison, hardware RAID is faster and more reliable and has little to no CPU overhead. Software raid can be CPU intensive and not as reliable.
As for the CDB-6 RAID drivers... I personally gave up. I talked with HP's Linux department at length and there is no source code available for the CSB-6 drivers. They released some RPMs and floppy images, but they are only available for a few Linux distributions (Fedora is not one of them.) Not a single one of the drivers released by HP/Compaq supports the 2.6 kernal so it does not look very good.
I ended up just disabling the onboard RAID controller completely and went with an Adaptec RAID card (which worked out of the box) configured as a RAID5 array with 4x300MB drives.
If you use RH9, RHEL2, HP does offers install floppy disc images that you use during the install process to provide the appropriate drivers during setup. (Hint: look for instructions on using a driver disc during an install of Linux...)
Good luck and report back if you manage to get it working in Fedora
Errr, you do if the Kernel does not even recognize the controller drives at all. (Which it does not with this esoteric controller.)
if I can see lspci and lspci -n maybe we can add that.
And I am always amazed how people seems to think using software raid is as good a solution as using hardware raid. Come on, there is no comparison, hardware RAID is faster and more reliable and has little to no CPU overhead. Software raid can be CPU intensive and not as reliable.
Note that we're talking about csb6 raid here. That *IS* software raid. You just get it from a binary driver instead of an open linux driver; but it's still software raid done by the main cpu.
Arjan van de Ven wrote:
Errr, you do if the Kernel does not even recognize the controller drives at all. (Which it does not with this esoteric controller.)
if I can see lspci and lspci -n maybe we can add that.
And I am always amazed how people seems to think using software raid is as good a solution as using hardware raid. Come on, there is no comparison, hardware RAID is faster and more reliable and has little to no CPU overhead. Software raid can be CPU intensive and not as reliable.
Note that we're talking about csb6 raid here. That *IS* software raid. You just get it from a binary driver instead of an open linux driver; but it's still software raid done by the main cpu.
Hmmm, I thought the CSB-6 was a low end hardware RAID. You configure the RAID in the HP BIOS - at least that is the way it works with the HP/Compaq implemtation - it is built into the motherboard. It also only supports RAID1, which does not support the RAID I want (RAID5), so I admittedly gave up on getting the CSB-6 from working without much of a fight.
Given the BIOS requirement I thought that would mean this is hardware based. (As you set up the array in bios even.) Of course, it is getting awfully confusing with all the "RAID" controllers that are being installed onto lower-end motherboards. By what you are saying it sounds like these "RAID" controllers are kind of like Winmodems... offloading the real work to the CPU and OS. Or am I still not getting this right??
I will try and get you the output of lspci and pspci -n for you to look at soon.
Given the BIOS requirement I thought that would mean this is hardware based. (As you set up the array in bios even.)
it's not a correct assumption anymore; yes you can write the magic sectors to the disk via the bios.... and the bios can even read the format so that you can boot from it (but the bios does it on the host cpu)
like these "RAID" controllers are kind of like Winmodems... offloading the real work to the CPU and OS. Or am I still not getting this right??
well it's basically pure software raid with bios boot support... (Note: with raid1 there is basically no cpu overhead so you won't notice... :)
On Sat, 2004-11-06 at 09:19 -0500, AWC Maillists wrote:
installed onto lower-end motherboards. By what you are saying it sounds like these "RAID" controllers are kind of like Winmodems... offloading the real work to the CPU and OS. Or am I still not getting this right??
yeah you are getting it right.... but the driver has to be binary only of course... because RAID1 is highly proprietary! (ha! there's like only so many ways you can do raid1 :)
fwiw, in practice linux MD raid will perform better than the software raid done by such drivers. The reason is in the on disk layout; linux md raid has the guarantee that the start of the partition is on a 4Kb boundary (by virtue of being per partition); the fakeraid drivers have to raid teh entire disk, which means partitions can (and generally will, since such raid formats advertise an non-even number of heads/cylinders) start not-on-a-4k boundary. If you do raid 0, this means that the places where the strides go to the other disk, are also not on a 4Kb boundary. Now the kernel will almost always do 4Kb (pagesize) IO's, when then have to be split on every stride boundary, which 1) is not cheap, and 2) means that you may have to wait for 2 disks to seek instead of one, etc etc.
On Sat, Nov 06, 2004 at 09:19:15AM -0500, AWC Maillists wrote:
installed onto lower-end motherboards. By what you are saying it sounds like these "RAID" controllers are kind of like Winmodems... offloading the real work to the CPU and OS. Or am I still not getting this right??
That would be overqualifying them.
There are really three kinds of raid floating around.
The first is pure software raid like the CSB6 raid, the ICH-R, most promise PATA controllers and so on. These have no hardware assistance for raid at all just a different BIOS (and often price). Almost every parallel ATA RAID falls into this (Some exceptions eg 3WARE and IT8212)
The traditional hardware raid controllers do all the raid in hardware or onboard processors - these range for simple devices like the 3Ware which is fast but basic to the aacraid which has full hardware logical volume management, live migration and the like. They can help if your PCI bus is the bottleneck or with raid5 but many of them underperform software raid (Intel make very good raid controllers called "Pentiumn IV" and a CPU upgrade is suprisingly cost effective as is SMP)
What are starting to appear now (although its an old idea one one the old Adaptec AAC-1xx cards did) are hybrid cards which do some things in hardware (such as XOR and buffering to keep PCI transfers down to one per IO) but do the rest in software - these are more akin to the "winmodem" world than perhaps the pure software raid. [although some winmodems are also awfully dumb too]
Alan
Arjan van de Ven wrote:
Errr, you do if the Kernel does not even recognize the controller drives at all. (Which it does not with this esoteric controller.)
if I can see lspci and lspci -n maybe we can add that.
And I am always amazed how people seems to think using software raid is as good a solution as using hardware raid. Come on, there is no comparison, hardware RAID is faster and more reliable and has little to no CPU overhead. Software raid can be CPU intensive and not as reliable.
Note that we're talking about csb6 raid here. That *IS* software raid. You just get it from a binary driver instead of an open linux driver; but it's still software raid done by the main cpu.
Server: HP Proliant ml330 g3
Onboard IDE controller for CD-ROM and one hard drive (only have CD-ROM connected to this right now) CSB-6 onboard raid controller w/no drives connected right now I can install a blank drive if you want. So with the above two IDE controllers, a total of six IDE drives can be installed onto the machine.
Adapatec RAID 2410SA controller w/enclosure kit w/RAID5 w/4x300mb driver Everything is installed onto this array 768MB RAM Fedora Core 2 w/all updates installed (using up2date using standard update site configured out of the box) including kernal
Sorry, no FC3RC5 anymore, the server has to be deployed next week, so I can not play with the release candidates anymore. :(
I suspect the output would be the same as FC3RC5 did not detect any drive attached to this controller during the setup process either.
lspci 00:00.0 Host bridge: ServerWorks GCNB-LE Host Bridge (rev 32) 00:00.1 Host bridge: ServerWorks GCNB-LE Host Bridge 00:03.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) 00:04.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5702X Gigabit Ethernet (rev 02) 00:05.0 System peripheral: Compaq Computer Corporation Advanced System Management Controller 00:06.0 RAID bus controller: Adaptec AAC-RAID (rev 01) 00:0e.0 IDE interface: ServerWorks: Unknown device 0217 (rev a0) 00:0f.0 ISA bridge: ServerWorks CSB6 South Bridge (rev a0) 00:0f.1 RAID bus controller: ServerWorks CSB6 RAID/IDE Controller (rev a0) 00:0f.2 USB Controller: ServerWorks CSB6 OHCI USB Controller (rev 05) 00:0f.3 Host bridge: ServerWorks GCLE-2 Host Bridge
lspci -n 00:00.0 Class 0600: 1166:0017 (rev 32) 00:00.1 Class 0600: 1166:0017 00:03.0 Class 0300: 1002:4752 (rev 27) 00:04.0 Class 0200: 14e4:16a6 (rev 02) 00:05.0 Class 0880: 0e11:a0f0 00:06.0 Class 0104: 9005:0285 (rev 01) 00:0e.0 Class 0101: 1166:0217 (rev a0) 00:0f.0 Class 0601: 1166:0203 (rev a0) 00:0f.1 Class 0104: 1166:0213 (rev a0) 00:0f.2 Class 0c03: 1166:0221 (rev 05) 00:0f.3 Class 0600: 1166:0227
I hope this helps.
-
Alan Cox -
Arjan van de Ven -
AWC Maillists -
Hewitt,William P - JSC