info-vax@ucbvax.ARPA (02/28/85)
From: Bill Mitchell <whm%arizona.csnet@csnet-relay.arpa>
We're beginning to lose our fascination with buying TU78s at $30k a whack
and are contemplating dual porting a TU78 between two 785s. I haven't
been able to get an entirely confident answer from DEC about how software
interacts with the dual-ported device, so I thought I'd ask the list.
The machines in question will be running UNIX (4.2bsd).
The basic question is: When one machine is using the tape, how does the
tape drive appear to the other machine? Does it appear to be off-line?
Would concurrent operations by both machines just overlap?
One person from DEC that I was talking to gave me the impression that
if you started both machines writing a tape, the writes would just
interleave in some arbitrary fashion. That is, if a write was in
progress by one machine, a transaction by the other machine would
just wait; i.e., the locking is on a per-operation basis. I would
consider this to be entirely satisfactory as long as (obviously
inadvertent) concurrent usage didn't sufficiently confuse one or
both of the drivers enough to crash the system.
Does anyone have experience with dual-ported TU78s on 4.2? What
are the facts?
Thanks in advance,
Bill Mitchell
whm.arizona@csnet-relay
{ihnp4,noao,mcnc,utah-cs}!arizona!whminfo-vax@ucbvax.ARPA (02/28/85)
From: (Stephen Tihor) <TIHOR@NYU-CMCL1.ARPA> With a dual ported TU78 you have three useful options on the little POST thumb wheel on the drive: (0) PORT A -- the system on Port A can use the drive. Operations from Port B will fail (1) PORT B -- just the reverse of above (2) PORT A/B -- either system can write to the drive interleaving I/Os on a command by command basis. No problem in a VAXcluster where the system software arbitrates to allocation of the tape drive and insists that only on process tree can have it at a time; Requires some care under non-clusted VMS systems but at least you have to allocate the drive exclusively on the system to use it so various tricks like having the drive always allocated to the console (or a background job) until the user asks for it in uch a way that a human or the two owning processes get to arbitrate the allocation. Uncomunicative VMS systems or any Unix system without the tape allocation patchs will rely on user kindness. Since users overwrite each others tapes NOW on our BSD 4.2 systems I wouldn;t hold out great hope unless these are basically single user 785s but ... \\ Stephen Tihor / CIMS / NYU / 251 Mercer Street / New York, NY 10012 // (( DEC Enet: RHEA::DECWRL::"""TIHOR@NYU-CMCL1.ARPA""" NYUnet: TIHOR.CMCL1 )) // ARPAnet: Tihor@NYU-CMCL1 UUCPnet address: ...!ihnp4!cmcl2!cmcl1!tihor \\ -------
info-vax@ucbvax.ARPA (03/01/85)
From: weber%delphi.DEC@decwrl.ARPA (Ralph Weber) RE: With a dual ported TU78 you have three useful options on the RE: little POST thumb wheel on the drive: RE: (0) PORT A -- the system on Port A can use the drive. Operations RE: from Port B will fail RE: (1) PORT B -- just the reverse of above RE: (2) PORT A/B -- either system can write to the drive interleaving RE**: I/Os on a command by command basis. No RE**: problem in a VAXcluster where the system RE**: software arbitrates to allocation of the tape RE**: drive and insists that only on process tree RE**: can have it at a time; . . . Hold on just a cotten pickn' minute here! VAXclusters arbitrate cluster-wide only for access devices which are known to be cluster accessible. HSC controlled disks & tapes, MSCP served disks, and dual-ported disks qualify as cluster-accessible. Everything else does not. (The system performs better that way.) If I were playing this game, I'd use options 0 and 1.
info-vax@ucbvax.ARPA (03/02/85)
From: (Stephen Tihor) <TIHOR@NYU-CMCL1.ARPA> Gee, I asked Kirby Altman that very question, about a shared tape drive in a cluster and he said that it should interlock properly. Are you certain that he was wrong? \\ Stephen Tihor / CIMS / NYU / 251 Mercer Street / New York, NY 10012 // (( DEC Enet: RHEA::DECWRL::"""TIHOR@NYU-CMCL1.ARPA""" NYUnet: TIHOR.CMCL1 )) // ARPAnet: Tihor@NYU-CMCL1 UUCPnet address: ...!ihnp4!cmcl2!cmcl1!tihor \\ -------
info-vax@ucbvax.ARPA (03/02/85)
From: TIHOR@NYU-CMCL1.ARPA Gee, I asked Kirby Altman that very question, about a shared tape drive in a cluster and he said that it should interlock properly. Are you certain that he was wrong? \\ Stephen Tihor / CIMS / NYU / 251 Mercer Street / New York, NY 10012 // (( DEC Enet: RHEA::DECWRL::"""TIHOR@NYU-CMCL1.ARPA""" NYUnet: TIHOR.CMCL1 )) // ARPAnet: Tihor@NYU-CMCL1 UUCPnet address: ...!ihnp4!cmcl2!cmcl1!tihor \\ -------
info-vax@ucbvax.ARPA (03/02/85)
From: nbush%sitvxa.BITNET@WISCVM.ARPA(Nicholas Bush) While the port A and port B positions of the thumbwheel are very nice in keeping one system from using the drive, DEC's distributed TFDRIVER gets a little confused about such things. The drive returns an interrupt code of "NOT AVAIL" if a system tries to access the tape drive when it is locked out. TFDRIVER considers this to be a FATAL DRIVE ERROR. Since the MOUNT command attempts to access the drive to mount a tape, you tend to get errors on the system which is locked out. (Note that you only get the NOT AVAIL interrupt code when the tape drive is actually online, but your port is locked out.) This caused us much grief when we first ran into it. I sent in an SPR and got a "not supported" answer, even though the mods to TFDRIVER are minimal. - Nick Bush Stevens Institute of Technology
info-vax@ucbvax.ARPA (03/03/85)
From: bellcore!martin@BERKELEY This is the second 4.2 site that i have worked at with dual ported TU78's, they work fine. Dual porting is much cheaper than buying another TU78. We keep the switches on the A/B position and expect people to come into the machine room and load a tape before typing a tape write/read command (say cpio, tar, dd, dump etc). Even with the switch in either the A or B position the other machine gets an OFFLINE message, which is passed to the user. You can either educate your users or not, either way it works. Martin Levy, Bellcore.