[Tfug] OT: Disk testing

[Ronald Sutherland]

I'm thinking that USB will not scale past a few HD's, I guess I'd 
personally be thinking along the lines of multiple PC's. With a test 
program that runs after startup in each. I'd probably also get some 
cheep IDE cards to add IDE channels, I've seen some that add 2 (or 4) 
IDE channels from HighPoint and others, and if I remember they claim to 
work in Linux. After adding 4 IDE channels, one master drive per 
channel, that should give 6 master IDE's total, keep one for system and 
use the rest for testing. Since I've never tried this sort of thing, I 
wonder if its possible to kill the power to an IDE master only and 
remove it while leaving the other masters running. Also I think that the 
PCI data bus will saturate around 5 to 6 HD's so more than that per 
system may not be faster, if I'm wrong about that then fill more PCI 
slots with IDE cards.


http://www.highpoint-tech.com/USA/r133.htm

Adding some mobile rack type things in system may help also.

http://www.kingwin.com/mobileracks.asp

Bexley Hall wrote:
> Hi,
>
> Forgive the OT post ... :<
>
> I'm looking for some ideas on how to hack together
> a platform to exercise disk drives.  Newer drives
> are so large that a comprehensive surface analysis
> takes a considerable amount of time!  So, doing
> multiple drives concurrently seems like a natural
> decision.
>
> But, the drives will have different geometries,
> access characteristics, etc.  I.e. obviously they
> can't be tested in lock-step with each other
> (no big deal).
>
> If these were SCSI drives, I'd have no problem;
> find a big enough JBOD and shove 5, 7, 12, etc.
> drives into it and, as The Fat Man would say,
> "away you go"!
>
> Unfortunately, they are IDE.  This poses two
> primary problems:
> - IDE controllers only handle two drives
> - IDE isn't designed to be hot swappable
> (i.e. unplugging the 'Master' while the 'Slave'
> is being exercised can perturb the bus, etc.)
>
> The hot-swap criteria is probably a must have
> since you want to be able to start the *next*
> disk's test as soon as one disk has finished
> (i.e. *while* other disks are still being tested).
>
> The "two drive per controller" issue implies that
> testing a lot of drives concurrently becomes
> problematic -- assuming you can use the "secondary"
> controller in a modern PC (keeping the primary
> controller for the application itself), you'd
> need to come up with several "IDE controller
> cards" just to give you the physical interface
> to the machine.  These would all be colocated in
> *one* machine so you have a tangle of cables
> (which have to be kept short!) in one spot.
> Add to that, the probable need for an auxilary
> power supply (to keep all of those loads off the
> PC's single supply) and you end up with an ugly
> mess.  :<
>
> I *think* the only practical solution using
> COTS technology is to use a bunch of external
> USB disk enclosures (!).  Those that I have
> seen seem to query the drive for it's geometry
> (vs. hard-coding some values in their own
> USB controllers).  So, replacing a drive and
> reapplying power should be all that is needed
> to "reconfigure" the USB device for the new
> disk geometry, etc.
>
> And, since they have USB interfaces to the host,
> the cable tangle is minimized -- you can locate the
> drives separate from the PC for ease of access
> (servicing).  Similarly, each device has its
> own power source -- capable of powering one
> drive -- so the power *supply* automatically
> grows to meet the number of drives being tested!
>
> It seems the only issue here would be USB bottlenecks.
> Especially if the I/F's were not USB 2.0.
>
> Can anyone see any flaws in my proposed solution?
> Or, can anyone come up with a *better* solution??
>
> Thanks!
> --don
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
>
> _______________________________________________
> Tucson Free Unix Group - tfug at tfug.org
> Subscription Options:
> http://www.tfug.org/mailman/listinfo/tfug_tfug.org
>
>