[Techtalk] Re: ATA RAID with Promise FastTrack
Scott Sandeman-Allen (RSCorp)
scott at rscorp.ab.ca
Mon Feb 17 19:04:31 EST 2003
> Any thoughts?
Yes. Sorry if I didn't read your post correctly. I'll go back and see where I
went astray. Never an intention to tell anyone what to do, just maybe a little
too much trying to read-between-the-lines. Again, sorry if I read things wrong.
> If anyone can explain the difference between "Linux native RAID" for [an
> IDE RAID] controller and plain old software IDE RAID, that may help to
> educate me. :-)
There is no fundamental difference in the two. Implementation is the key...
sorta like the 'doze VS *nix. Both are an OS, one just works better.
> In any case, it seems to me that there is an advantage in running RAID
> that
> is supported through the BIOS (whether we call that "hardware RAID",
> "pseudo-hardware RAID", or "Bob" I don't much care). ;-)
There is a distinct disadvantage to running Promise IDE RAID. Performance,
flexibility and even potentially security (by not being able to upgrade
kernels) et al are where you will suffer.
Testing done with the 3Ware RAID cards (an excellent product) shows that even
their native implementation of RAID is significantly slower than Linux's. Also,
on modern CPUs, the overhead for Linux RAID is not onerous in the least. It is
rare that I've seen RAID take more than a percent CPU under normal operation.
A very important feature with Linux RAID is the persistent superblock. This is
a chunk of the drive which tells the kernel/RAID drivers what device a
partition is. If you have to move drives from one machine to another or you
have to re-install or even upgrade your system, the superplock helps keep
things in order.
Also, a sweet function of Linux' RAID flexibility is to have part of the drive
RAIDed, while another part is not. You could say RAID-0 your /var or even just
/var/www for performance while RAID0 another partition for fault tolerance.
> Maybe I'm wrong.
Happens to me, usually I don't break anything thankfully 8-)
Hope this helps,
S.
More information about the Techtalk
mailing list