[mythtv-users] The Bigger... Disk contest, Fall 2007 edition

[f-myth-users at media.mit.edu]

    > Date: Fri, 19 Oct 2007 09:22:10 -0700
    > From: David Brodbeck <gull at gull.us>

    > On Oct 18, 2007, at 12:50 PM, Jay R. Ashworth wrote:

    > > On Thu, Oct 18, 2007 at 12:22:47PM -0700, David Brodbeck wrote:
    > >>> The SCSI drives will; I've done it.
    > >>
    > >> Fair enough, but I don't think valid anymore to assume SCSI = "server
    > >> class" and non-SCSI = "desktop class."  The Seagate Barracudas have a
    > >> 24x7 duty cycle, whether they're SAS or SATA.
    > >
    > > Well, that's what we use, and we had one decide, about a year into  
    > > it's
    > > duty, maybe 2 tops, that if you tried to read a certain range of
    > > sectors, *it would make the IDE controller drop off line, until
    > > powercycle*.

    > Well, if you want to talk about the electrical robustness of the  
    > interface, I agree IDE is not very good.  Neither is SCSI, though --  
    > one bad device can bring down all of them on the daisy chain, which  
    > in the case of SCSI can been up to 15 devices instead of just  
    > two. ;)  I think SATA's "one drive per port" concept is a good one.

Me, too, for the same reasons.

    > I kind of soured on SCSI after a while because it was so difficult to  
    > get all the devices to agree on proper termination.  Eventually you  
    > get tired of fiddling with (and losing) the little resistor packs.   

And, in the early Mac world, whether devices needed terminators or
were "auto-terminating" or maybe were "auto-terminating and if you put
your own terminator on anyway, bad things would happen".  Bleah.

And remember the special IIfx-specific black terminators, that nothing
else in the entire model line needed?  Oh boy, what fun!  And see above
wrt "auto" termination (not).

    > And you can get yourself in trouble in strange ways with external  
    > SCSI, even do damage to devices with it.  I once had a tape robot  
    > that kept failing under warranty.  After a few months it would stop  
    > talking to the computer and have to be sent in for repairs.  After a  
    > couple of rounds of this, the tech support folks happened to ask how  
    > long a cable I was using.  We determined it was too long and I  
    > swapped it for a shorter one.  The tape drive still didn't work and I  
    > exchanged it, but I kept the shorter cable in place, and it never  
    > failed again.  Ironically, the too-long cable was the one that had  
    > shipped with the drive.

Oh ugh.

I have a plausible explanation for that---a longer cable has more
capacitance, hence requiring more joules/transition to meet the
slew-rate requirements to avoid clock skew.  It's entirely possible
that the line drivers on the robot managed to meet the slew rate spec
(since after all, you weren't getting data errors) but at the cost of
dissipating too much power to do it, and eventually cooked.  I'd argue
that the -right- design there was to thermally limit the line drivers
(hence failing immediately with the long cable by giving massive data
errors or not appearing to be online at all) instead of having an
overlong cable be capable of cooking the drivers, but it's easy to see
how such a mismatch could have arise, and how it could have gone
undetected for a while.  (Still bad design on the drivers, of course.)