I previously mentioned the problem I had with my RAID system when I powered it back on.  It really got me focused on the fact that RAID isn’t really such a great method for preserving files.  It’s good for a single drive failure, and it’s good for keeping a system online even with a bad drive, but anything beyond that means total data loss.

When I ordered the replacement drive I also ordered a couple of plain old 250GB PATA drives (the ones that got “thunked” onto my doorstep yesterday).  I’d decided that I was going to keep a second system to back up the first before replacing the bad drive and rebuilding the array.

A couple of weeks ago I had resurrected an old system and installed Open SuSE 10.1 on it.  At the time I was mostly playing around with putting a scanner online (a RadioShack PRO-2052 that I got on clearance) using Icecast.  But since this system also had a built-in Highpoint 370 “RAID” controller it meant that I had two extra IDE channels that I could use to create a mirrored drive array using the Linux software RAID tools (the HPT370 is actually just a fancy IDE controller with a little hardware support for RAID, but not a true RAID controller).  Anyhow, the system was working and it was running headless in a corner of my living room (one of my motivations for Icecast and the headless living room setup is that my office is an EMF wasteland, making it difficult to get a decent signal).

I installed the new drives and booted the system.  Once it was on the network again I used Yast2’s partition tool (being headless, I did this using Cygwin’s X-server on a PC) to create the RAID array, format it, and add it to the filesystem table.  It took me a minute or two to figure it out, but once I did I was surprised at how easy it actually turned out to be (select each drive, add a primary unformatted partition of type Linux RAID, select RAID drop-down, select each partition and hit “Add”, select RAID 1, select Reiser filesystem, apply changes). 

I’m always a little suspicious when something is too easy, but it all appeared to be working so I started an Rsync of my home directory and left to walk the dog.  When I got back I saw that the drive lights were on solid, so I thought it was working.  A little later I tried to login, but couldn’t access the system. 

Once I got it rebooted, a bit of examination showed that both of the HPT370’s IDE channels as well as the wireless card were sharing IRQ 11.  Everything is PCI, and it’s technically supposed to be able to share interrupts, but I don’t like interrupt sharing.  Further, with the RAID array and the wireless card on the same interrupt, it would seem to be just asking for trouble.  Every operation involved in copying data seems to be piled up on one interrupt (i.e receive data on wireless card, write data to hard drive on first channel, write data to drive on second channel).

Unfortunately, this motherboard has a brain damaged implementation of PnP configuration in its BIOS, so that “unsharing” the interrupts involves physically moving devices to different slots.  For example, this motherboard is hardwired to share an interrupt between the HPT370 controller and whatever device is in PCI slot 2, so whatever interrupt you choose for slot 2 (INT PIN 2 assignment in the BIOS), it’s shared with the HPT370.

I also learned that moving a wireless card causes SuSE to “forget” the card (you have to go into Yast’s network configuration and delete the original entry for the adapter and configure the new entry from scratch). 

Once I got through all that nonsense I started the Rsync.  It’s not exactly setting any speed records, as it’s using ssh over my wireless LAN.  But so far it’s copied about 18GB without hanging (as opposed to just under 2GB yesterday).  So there’s only another 140GB or so to go.

At this rate it’ll be finished in about a week.  As long as it doesn’t hang.