Dual porting UDA50 drives under 4.2

dave at RIACS.ARPA dave at RIACS.ARPA
Thu Jan 3 05:21:05 AEST 1985


If you are serious about attempting the dual porting of RA81 drives on
a the UDA50 it is essential that you obtain a copy of the UDA50
Programmer's Kit which is mentioned in the user documentation you
should have received with the controller/drive.  I have heard that they
are no longer offerred by dec, and we a duece of a time getting one,
but I don't see any realistic options for accomplishing the work.  What
follows is the result of a fairly quick reading of the above
documentation, and some legend.  A more detailed examination, and some
experimentation may blow all of this out of the water.

I think the bottom line on such an attempt will be that it just isn't
worth the effort on most systems.  It looks to me like dual porting via
UDA50s is ok for backup operation, but was not designed for high speed
dual system access to RA81s. When I looked into the possibility of the
dual porting of some of these drives, I was told the the minimum time
between successive hosts' access going through separate UDA50s to a
single drive was on the order of 600 milliseconds.  I can't determine
the actual minimum time from the documentation because the
documentation which I have seems to require the expiration of a host
timeout value not used in 4.2 BSD; there does not appear to be a way
for a host to release its controller's access to a dual ported drive,
explicitly.  There is an indication that controllers must support a
host timeout value minimum of ~10 sec, but the actual minimum value
implemented for a UDA50 is unknown to me. I did not verify the minimum
host switch time experimentally when I had a configuration on which I
could have because even if as low as 600 milliseconds, that was too
long.  Now I am in a one machine environment.

As I read the documentation, a drive can be "online" to only one
controller at a time, although there are provisions in the mscp
protocolfor multiple hosts on a shared controller (i.e., an HSC50 type
lash up).  A host which attempts to access a drive which is online to
another host via another controller is said to receive an end message
code which says the drive is "offline" and the subcode indicating that
the drive is online to another controller. This amounts to a kind of
dynamic lock on the drive resource per controller.  All current
implementations of the 4.2 BSD UDA50 driver with which I am familiar
would look at the completion flags, see !M_EF_SUCC, and assume a hard
error; the distributed 4.2 BSD driver would report some fairly cryptic
information such as the logical block of the attempted transfer in
hexadecimal, and return the error to the process attempting the
transfer.  The section of the documentation I have does not even
contain a section it refers to on multi porting, but it is a
preliminary version.

Handling the online to another controller end message, all by itself,
seems easy.  Although I did not examine the changes required to support
the multi-porting in the 4.2 BSD driver, I don't believe it would be too
difficult to adopt a simple strategy of sleeping, and retrying the
operation later.  This might not be acceptable to user, or system
processes, however.  Another strategy might be to report the problem
"upstairs" and let the file system code decide what to do about such a
circumstance. 

There may be someone out there who has successfully attacked the dual
porting problem, and if so, I would be interested in hearing about it.

dave
----------



More information about the Comp.unix.wizards mailing list