That AAA-131U2 appears to be cheap ass (and I got it for cheap, indeed).
It has quite standard AIC-7890AB with SCSI BIOS which looks identical to
AHA-2940. You can’t set up RAID without using a software for a supported
OS (Windows/Netware/Unixware). It does have cache however (up to 64Mb of
I know that other RAID boards, such as Intel, Mylex, AMI and LSI usually
have i960 or some equivalent CPU on board. Most of them use LSI Logic
SCSI chips, such as 53C1010 and have much wider OS support than Adaptec,
probably because they don’t rely on host driver to perform RAID
functions. Adaptec apparently does, even though it has hardware XOR
engine there is no general purpose CPU on board to drive it
The lesson is, I’ll stay away from Adaptec RAID in future
BTW, QNX enumerator hung on that AIC7890AB (at the ‘looking for aha7…’
stage) anyway. I’ll just use it in Windows then.
Speaking about troughput, major advantage of SCSI is that you can
disconnect from drive and connect to another one as soon as you’ve
queued an I/O request, whereas with IDE you’d have to wait till it
completes. So SCSI RAID would be able to use several drives at the same
time. PCI bus limitation won’t really apply to Ultra2 single-channel
RAID, it is limited to 80Mb/sec. Still usable with 3-4 drive arrays,
especially with large cache it should fly on most I/O operations.
Warren Peece wrote:
I’m totally talking out my arse here, but I seem to recall from previous
discussions in another lifetime that some of these PCI RAID controllers appear
as two or more individual SCSI controllers and it’s totally up to the
O.S./driver to handle the redundant I/O, drive rebuilding, and so on. It may
vary by manufacturer exactly how much intelligence they have on each board.
That XOR processor is used to figure the parity data for things like RAID 5 so
you don’t beat the heck out of the CPU. But unless there’s a processor on that
card along with a bunch of RAM and it presents itsself as a single SCSI
controller device to the O.S., my guess (and it is truly just a guess) is that
you’re going to have to write it ALL.
-Warren “nothing ventured, nothing to make fun of” Peece
“Mitchell Schoenbrun” <> email@example.com> > wrote in message
news:> Voyager.011213185131.8985A@schoenbrun.com> …
| I know enough to be dangerous here. For a typical external RAID, to
| a SCSI driver/Controller card combination, the RAID looks like a normal
| SCSI hard drive, or drives. There’s not much to fuss about. Interaction
| with the external RAID controller is done either via a serial link or
| as is becoming more common, via an Ethernet link. From this interface
| you can define RAID sets, and do repair work, such as replacing a
| dead drive and having controller repair it. An example would be
| if you are using RAID 1 (Mirroring) the current good version would need
| to be copied in its entirety to the new drive.
| Now, when you go to an internal RAID controller, a driver will again
| see the RAID set as just a SCSI drive. The controller should trasparently
| take care of any issues like redundant I/O. However the extra functions
| like defining the RAID sets will have to go somewhere.
| For one product I worked with, the Vortex controllers, this functionality
| was provided through an ESCAPE during boot into their custom BIOS. The
| board itself stored information on RAID set definition in NVRAM.
| One downside to this arrangement is that there was no concurrent RAID
| repair. If a RAID set was damaged and the system was running in a
| degraded mode, you would hear a warning beep, but you would have to
| shut down and repair from the BIOS before starting up again. No
| hot repairing.
| An alternative would be to provide an interface so that a utility could
| dynamically do the repair. I don’t know whether any of the existing
| board level RAID’s do this, but there’s a big downside for QNX.
| Most manufactorers won’t support QNX directly. This adds a big
| extra chore to a driver writer. It’s also possible that some
| boards will not store the RAID set information on the board, thus
| it would need to be on the disk as part of the file system, or
| possibly hidden in a partition.