Hi,
Would it be advisable to use SW-RAID using 2 different SATA controllers. My system happens to have both a VIA VT8237 and SIL3114 SATA controller, and I thought for both performance reason and redundancy using both for a 2 disk RAID1 array would be best.
But it's possible that SW-RAID does not like or cannot overcome problems with such a setup or that one of these drivers is known to have issues.
Any insight is welcome :) -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Sat, 2005-06-25 at 04:01 +0200, Dag Wieers wrote:
Hi, Would it be advisable to use SW-RAID using 2 different SATA controllers. My system happens to have both a VIA VT8237 and SIL3114 SATA controller, and I thought for both performance reason and redundancy using both for a 2 disk RAID1 array would be best. But it's possible that SW-RAID does not like or cannot overcome problems with such a setup or that one of these drivers is known to have issues. Any insight is welcome :)
Let's talk "driver ... issues" then.
You just hit on one of the major reasons I don't use "raw" ATA/SATA channels. Remember, [S]ATA is "intelligent drive electronics" (IDE), and the so-called "controllers" are little more than PCI-to-ATA bus arbitrators. That means that the CPU and the drive itself must communicate properly, through that arbitrator.
If the history of [S]ATA in Linux (among other, open source OSes with their own drivers) is a testament, all sorts of controller register settings and the IDE "intelligence" on the drives themselves _regularly_ have issues. Nothing is more enfuriating than to do a kernel upgrade and be treated to a new slew of ATA chipset-drive timeouts, performance issues and, in some cases, even corruption.
That's why on servers or critical desktops, I splurge and get a $125 3Ware Escalade 7006-2 or 8006-2 card. That way the kernel is far removed from all sorts of IDE non-sense, and 3Ware can work with vendors to ensure compatibility between its ASIC-ATA and the drives. Just like proprietary vendor drivers for those "other" OSes. The actual IDE implementations in [S]ATA discs are particularly nasty and sometimes, quite often, non-ATA standards compliant in several ways.
Now let's talk "performance."
You're still pushing 2X data through your memory-I/O interconnect for software RAID-1. If you have an "intelligent" storage controller, then you only push 1 copy, and the card itself replicates to both channels. Now if you're really worried about controller failure, get 2 cards and put them on separate PCI[e/-X] busses (not just slots), then mirror across to minimize the performance hit.
BTW, there is a table and some figures on the "performance hit" of doing software RAID-1, RAID-0+1 and RAID-5 in the article "Dissecting ATA RAID Options" in 2004 April Sys Admin (not available on-line).
One figure shows how the "performance hit" of doing software RAID is _not_ the actual XOR operation. The _massive_ performance hit is when you have to read _all_ data from the drives into memory, and then push _all_ data to the CPU just to calculate the XOR. The "hit" is massive in the interconnect-I/O department, and _not_ the actual XOR.
Which is why it's far, far better to put the XOR operation on the card, where you're pushing just 1 copy of data (and it does everything locally, away from the rest of your system).
On Friday 24 June 2005 22:01, Dag Wieers wrote:
Hi,
Would it be advisable to use SW-RAID using 2 different SATA controllers. My system happens to have both a VIA VT8237 and SIL3114 SATA controller, and I thought for both performance reason and redundancy using both for a 2 disk RAID1 array would be best.
But it's possible that SW-RAID does not like or cannot overcome problems with such a setup or that one of these drivers is known to have issues.
Any insight is welcome :)
I have done it in the past with with mediocre success... drive failure brought down the box - but once I disconnected the drive everything worked off the mirror. Other than that, it seemed to do its job. But then again, on the web you hear from all the people with issues with linux software raid - sata or not..
If you have the money and its something important, buy a hw raid controller - 3ware 8006-2 controllers are fairly cheap (around $130) and so far I haven't had any issues with any of the ones I use. They are really worth their money... and no, I don't work for them :-)
Peter.
I have done it in the past with with mediocre success... drive failure brought down the box - but once I disconnected the drive everything worked off the mirror.
Could that not be caused by your pin setting on the drives, since the master was still trying to over ride the slave........?
Best Regards, Jon McCauley
On Saturday 25 June 2005 00:11, Jon McCauley wrote:
I have done it in the past with with mediocre success... drive failure brought down the box - but once I disconnected the drive everything worked off the mirror.
Could that not be caused by your pin setting on the drives, since the master was still trying to over ride the slave........?
SATA doesn't have jumpers for master/slave - each drive has its on dedicated port on the controller.
Peter.
On Sat, 2005-06-25 at 00:19 -0400, Peter Arremann wrote:
SATA doesn't have jumpers for master/slave - each drive has its on dedicated port on the controller.
Many of the actual ATA standard revisions actually state this also for parallel ATA. Point-to-point UDMA is not supposed to be between more than one drive.
Of course, the legacy Programmed I/O (PIO) Enhanced IDE interfaces allowed this, hence why vendors kept offering it even for UDMA drives.
Quoting Jon McCauley jmccauley@ontarioweb.ca:
I have done it in the past with with mediocre success... drive failure brought down the box - but once I disconnected the drive everything worked off the mirror.
Could that not be caused by your pin setting on the drives, since the master was still trying to over ride the slave........?
Probably not. Linux software RAID drivers do a nice job, if your hardware is healthy. If you have one drive "half-dead", usually the driver is not smart enough to stop using it, which often results in frozen box. It just keeps retrying to access failing drive, eventually blocking all disk I/O. I've run into it several times. Physical removal of failing drive is the only option.
I've no idea why the driver simply doesn't give up on the disk it has problem accessing, marking it as failed. Probably a case of missing code to implement the functionality ;-)
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.