I am running 5.2-RELEASE with a Promise S150 TX4 Serial ATA RAID controller and a couple of WDC SATA drives at RAID 1. I am noticing some behavior that does not seem right to me. Systems boots fine on the two mirrored drives. If I disconnect the drive on channel 2 then the system continues to run. However if I disconnect the drive on channel 1 it dies. It appears that there is a primary drive on channel 1 and a secondary on channel 2 and the system is running on the primary. Perhaps I am confused on my ideas of RAID 1 but I was under the impression that either drive could fail and the system keep going. Am I wrong? If I am not does anyone have any ideas? If I reboot after the drive on channel 1 fails I can recover and boot off the drive on channel 2. However, the Promise S150 BIOS throws up an error message about the drive failure that requires manual intervention before boot can proceed. There does not appear to be any way around that. This, IMIHO, is brain dead and makes the controller useless for any remote operation. If this is SOP for Promise then can someone suggest a SATA RAID controller that behaves in a more sane manner? -- Tom Glover
On Fri, 16 Jan 2004, Tom Glover wrote:> > I am running 5.2-RELEASE with a Promise S150 TX4 Serial ATA RAID > controller and a couple of WDC SATA drives at RAID 1. I am noticing some > behavior that does not seem right to me. > > Systems boots fine on the two mirrored drives. If I disconnect the drive > on channel 2 then the system continues to run. However if I disconnect the > drive on channel 1 it dies.Can you explain "dies"?> If I reboot after the drive on channel 1 fails I can recover and boot off > the drive on channel 2. However, the Promise S150 BIOS throws up an error > message about the drive failure that requires manual intervention before > boot can proceed.This is normal for Promise and most ATA RAID, since thats likely to be the only warning you'll get about a missing disk. Also, some operating systems are not good about bumping the generation numbers AT ALL, and you can end up with unsynchronized mirrors if you continue. With the mirror, you won't lose your data, but its not designed to be fault-tolerant in a runtime sense. I don't know why you get differing failure modes between disks, though -- perhaps you aren't using the right disk device? You should be using ar0.> There does not appear to be any way around that. This, IMIHO, is brain > dead and makes the controller useless for any remote operation. If this > is SOP for Promise then can someone suggest a SATA RAID controller that > behaves in a more sane manner?You've discovered that ATA RAID is software RAID with hardware assist. If you want more transparent ATA RAID, you want 3ware. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org
Some questions on the Promise Supertrak SX6000 before I go and spend money on it .... Has anyone got one running where they can boot of the card? Preferrably on version 5.2 using RAID 1 but ..... Has anyone tried pulling a drive under RAID 1 on a running system? Should keep right on running but need to be sure. Any other problems with this card? -- Tom Glover
Tom Glover <tomg@egg.net> wrote in <Pine.BSF.4.58.0402050804340.14155@enema.egg.net>: tomg> Has anyone got one running where they can boot of the card? Preferrably on tomg> version 5.2 using RAID 1 but ..... tomg> tomg> Has anyone tried pulling a drive under RAID 1 on a running system? Should tomg> keep right on running but need to be sure. tomg> tomg> Any other problems with this card? I am using a SX6000 with 4 drives/RAID0+1 configuration on my FreeBSD 5.2-CURRENT box as of 2003/12/12 (not the boot disk, though). It should also be supported on 5.2-RELEASE. The dmesg says: |FreeBSD 5.2-CURRENT #0: Sat Dec 13 02:48:01 JST 2003 (snip) | pst0: <Promise SuperTrak RAID> on pstpci0 | GEOM: create disk pst0 dp=0xc299998c | pst0: 234603MB <PROMISE TECH. I2O RAID DEVICE> [29907/255/63] on pstpci0 | pstpci0: [MPSAFE] The hot swap (with SuperSwap) works fine and it is tolerant of relatively heavy load. However, it occasionally stops working and puts the following warnings: | Jan 29 22:56:50 kernel: pst: timeout mfa=0x0033cbf0 cmd=0x01 | Jan 29 22:57:00 kernel: pst: timeout mfa=0x0036d990 cmd=0x01 | Jan 29 22:57:10 kernel: pst: timeout mfa=0x0032e870 cmd=0x01 | Jan 29 22:57:20 kernel: pst: timeout mfa=0x003e99b0 cmd=0x01 I do not know the trigger, but it seems to occur once in two or three months. -- | Hiroki SATO -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20040206/6c56d4c9/attachment-0001.bin