All trials with the old drives came out fine.
PATA 80 conductor with drives set as M/S.
Never did I see a problem with the OS recognizing a failed drive, nor was there a problem in bringing the orphan back as a spare. Nor have there been any issues in file transfers to and from the hacked snap 2000 from PCs, Macs, and other snaps.
The new WD 250's came in and are now building into a Raid 5. Thanks for the heads up on the 1TB issues. The 700GB Raid 5 will be fine.
IDE cable
My opinion about the issue of 80 vs 40 is that the 80 was designed to be backward compatible and is preferred for reasons of signal integrity over the 40. The chipset in the 2000/4000, which is capable of UDMA 33 (still trying to find a debug command that shows the pci setting) is not going to be bothered by the additional ground wires as the pin outs are the same.
What is different is the "special" cable in the 4000's, which is nothing more than a standard 40 conductor cable sense ribbon. These CS 40s put the master at the middle and the slave at the end when the drive is in CS mode. The 80 conductor puts the master at the end when in CS. I imagine this would cause the OS to loose track of the array since the drive numbering routine is based on primary/secondary- master slave designations as set by the hard drive if a cable swap was made without taking the cable drive placement into consideration.
2000/4000 Drive config
Primary master-drive 1 (drive slot 0)
Primary slave-drive 2 (drive slot 1)
Secondary master-drive 3 (drive slot 2)
Secondary slave- drive 4 (drive slot 3)
The cable is overridden by the drive when in M/S and it is the drive that communicates with the chipset via the bios (which we don't really know about even with its FreeBSD base).
In my case with the hacked 2000, I saw a change in how the OS/bios read slaves when the hardware was still set at 2.0.0 (no slaves seen after the upgrade). When I upgraded to the version 4 snap os both master and slave were seen. Version 3 only needed the model change to work as a 4000 with 4 drives.
Aside from drive firmware issues or cables that don't introduce interference, there's power and heat issues for drives when hacking the 2000. Lot's of variables can cause the system from not working correctly.
Here's my setup. It's not pretty, but it functions fine it seems,
so far.
256MB ram, shielded 80 conductor PATA cables, drives set as master and slave by jumpers, fan cooling and external power for the drives controlled by a relay pulling off of the snap 12 volt line.
Round 2 of testing to begin once the raid builds with these WD 250s. Let's hope my little home server continues acting like a champ. But we all know what hacking can bring: wasted time and doorstops
