>It turns out that for some reason mkreiserfs only allocated >60G on my 120G >Raid array. I rebooted on my 1.4 LiveCD and attempted to >debug_reiserfs my >array, but wound up getting a screen full of I/O errors on one >of my drives >(the first one of the array). I suspect it's not actually the >drive, but the >driver that's at fault. > >In any case, I'm completely fed up with the Promise driver and >the ataraid >functionality (or lack thereof) in the kernel. hdparm can't >read the array, >mkreiserfs can't seem to make use of more than one drive's >worth of space, >etc. It's a disaster. After spending weeks of calendar time >and dozens of >hours trying to get it all to work, I'm backing off. > >I think I can tell the TX4 RAID card to not bother with an >array and just >run the 4 drives as independent, normal drives. Hopefully that >will allow >the kernel to better deal with them. Then, I'll attempt to use evms to >cobble them together into a software RAID 5 configuration. > >My only regret is that I'll no longer be using the RAID card >to its full >extent. However, I've also read some interesting opinions that >talk about >how a low-end RAID card (such as the tx4) can be a bottleneck >on higher-end >systems. Mine's a dual-mp 1.4Ghz (1600+) configuration. Such >opinions say >that on such a multi-processor, relatively fast system >software RAID can >actually be *faster* than relying on a card such as the tx4. I >hope that's >true! > >Eric I've had good luck with Linux software raid arrays. It's so durn easy, I don't see any reason to bother with the low end RAID cards. (The more expensive cards can offer advantages not otherwise available.)
I would wonder about a software RAID 5 array, however. Doesn't RAID 5 involve a fairly robust algorithm that might drag the processor down a bit? I don't really know and am somewhat curious about this, as I have been considering the same thing on a file server. -rex -- [EMAIL PROTECTED] mailing list
