7 DATs, 2 SCS cards

[Robert G. Brown]

On Thu, 19 Feb 1998, Derek Seaman wrote:

> I am going to be constructing a system with 7 HP C1599A 4mm DAT drives, 2
> 2940U SCSI cards, and 1 Seagate ST34572 HD and 1 Plextor 12/20x CD-ROM. The
> DATs will all be on one card and the HD & CD-ROM will be on the other SCSI
> card.

I have a system with one HP tape (C1537A) tape and two similar Seagate
HD's on a 2940 UW.  The tape works fine; I can't tell you if putting
seven tapes on a single SCSI controller will work without hacking the
kernel (perhaps drivers/scsi/st.c?) a bit -- there are only two st?
devices in /dev on my system and I don't know offhand if there are any
matching hard coded limits in st.c (couldn't see any).  At the very
least you will have to increase the number of minor device numbers and
generate st[0-6] in /dev.  Perhaps somebody more expert could tell you
if there are other hacks you might need.

My only remark would be go with UW instead of U.  My tape drive, at
least, comes up W but only 10 MHz for a total throughput of 20 MB/sec --
the UW channel gives you more bandwidth to split up between your tapes
and hence better parallelism.  The marginal cost is negligible.

> This system will be used to make tape copies which will be released to the
> U.S. Navy Fleet, so system stability is an absolute must.
> 
> Does anyone see a problem with the above setup? The 7 DATs will be in an
> external case using Granite Digial Teflon SCSI cables and terminators. I
> spared no expense with cables and terminators. 
> 
> Which Kernel/SCSI rev. is the most stable in terms of SCSI drivers? This
> system has to be rock solid. All 7 DAT will be used at once so the SCSI bus
> will be QUITE busy.

I think that if you are really planning to run all 7 DAT at once you
would probably be better off splitting them across the two controllers.
But I'll defer that to more expert persons.  If you put four on one and
three on the other, you would get maximum parallelism in all seven
channels - I "think" (from what I recall of SCSI) that a UW controller
could be writing in parallel on four 20 MB/sec devices at once, and (if
the system were utterly quiescent) you would still have some PCI
bandwidth leftover for the second controller and its burden of tape
devices.

> 
> Any comments would be greatly appreciated. The system will be running Red
> Hat 5.0.

Two strong suggestions:  Don't plan on engineering the system entirely
ahead of time.  You may well have to build it up incrementally to
determine points of instability and do some work to overcome the
instabilities you encounter.  Designs that work on paper do not always
work in practice, especially when scaling designs from the zone where
everything is known to work well to the bleeding edge, which you are.

Second suggestion is to reconsider running Red Hat.  I think of RH as
"predigested" linux; it is designed to be user friendly, but NOT expert
friendly.  I think that it will be much harder under RH to make
complicated things work if they don't work on your first try or if you
scale a hardware installation way out of the comfort zone assumed by
RH's system configuration team.  I'd personally use slackware (sort of
the minimalist, expert friendly linux distribution) but any distribution
where it is easy to hack rc boot and system configuration scripts would
do.  Since you'll almost certainly be cutting custom kernels, too, you
don't want a system that assumes that you'll build a kernel according to
a specific configuration re: modules vs. builtin devices, and so forth,
which again I believe RH does (at least "out of the box") and slackware
doesn't.

If you're not sufficiently unix-steeped to feel comfortable handling a
bit of kernel hacking and the /etc system configuration files without a
GUI-based interface, I'd consider hiring a consultant who is.  I think
that there are plenty of them who listen in on these lists...

   rgb

Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu




To Unsubscribe: send mail to majordomo at FreeBSD.org
with "unsubscribe aic7xxx" in the body of the message