Thanks for the detailed information. Starting to make sense. Bogdan --- "Bryan J. Smith" <b.j.smith at ieee.org> wrote: > On Wed, 2005-05-18 at 20:23 -0700, Bogdan Nicolescu > wrote: > > My first attempt at RAID... > > I purposely call it Fake/Free RAID (FRAID) for a > reason. > It is a _regular_ ATA controller with *0* extra > hardware. > There is a "trick" 16-bit BIOS that can setup some > RAID > organization. > > It is _useless_ once a 32/64-bit OS boots. > > > Tried a different distribution with the latest > kernel, > > and indeed the PTA drives on the Promise > controller > > were recognized but they were recognized as two > > separate drives while the controller was in RAID > mode > > (rather than IDE mode). > > Correct. Because the system sees the "raw" ATA > channels. > There must be a "trick" 32/64-bit driver to match > the > "trick" 16-bit BIOS. > > This "trick" 32/64-bit driver contains _all_ of the > RAID functionality. *0* is in the hardware, because > the > hardware has *0* RAID firmware other than the > ultra-simple > stripe/mirror access when the 16-bit BIOS is > booting. > > About the same 2-3 companies write these drivers, > and > _all_ vendors license that code. Because it is the > core > IP of those companies, they will _never_ release it. > As such, the drivers are _always_ "closed source" > and > really only available for Windows. The few > companies that > do release Linux drivers release kernel > version-specific > ones that are binary-only, no source code. > > There is a "clean-room" GPL ATA RAID driver in > ataraid.c. > And then interface drivers in hptraid.c, pdcraid.c > and > silraid.c, but they _rarely_ work with most "FRAID" > cards accept for very old ones. And they are > _slower_ > than the OS' RAID (NT LDM, Linux LVM/MD, etc...). > > > Are you saying that even if the drives are > recognized, > > I will not be able to implement RAID in hardware > mode? > > There is _no_ "hardware" mode. The system _always_ > sees > the drives. There must be a "trick" driver to > "hide" the > drives and make them seem organized. > > A _true_ hardware RAID controller _always_ has > on-board > intelligence that directly controls the drives, and > has > the RAID firmware on-board. In those cases, the > system > talks to that on-board intelligence (e.g., > microcontroller > or ASIC) and _never_ actually sees the drives. > Because > all of the RAID intelligence is in the firmware, the > OS > driver is just a basic block driver, so they are > GPL. > > Examples of true hardware ATA RAID include Promise > SuperTrak > (_not_ the FastTrak), Adaptec 2400A/2800A, some (but > not > all) LSI Logic MegaRAID and 3Ware Escalade products. > > These cards cost between $125-$500+. You will _not_ > find a _true_ hardware RAID controller on a > mainboard. ;-> > > > Any other options installing CenOS 4 on > unsupported hd > > controller besides: > > a. install CentOS 4 while drive in recognized hd > > controller > > b. get new kernel > > c. compile/install new kernel (without pulling my > hair > > out) > > d. move drives to unsupported hd controller > > e. set controller to IDE mode > > f. boot using new kernel (while praying) > > g. do software RAID > > Yes, software RAID is typically _faster_ than these > FRAID cards. > Why? Because instead of using the logic of the > FRAID controller, > you get the logic of the OS' buffering. The OS' > buffering will > commit writes and interleave reads far better than a > FRAID > controller's "trick" driver logic. > > > -- > Bryan J. Smith > b.j.smith at ieee.org > ----------------------------------------------------------------- > > Beware of those who define their preference in terms > of hate of > another option, and not on the positive merits of > their selection > > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos >