Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!watmath!clyde!cbosgd!ihnp4!mhuxn!mhuxm!sftig!sftri!sfmag!eagle!ulysses!allegra!bellcore!decvax!wanginst!ucadmus!harvard!seismo!brl-tgr!tgr!dave@RIACS.ARPA From: dave@RIACS.ARPA Newsgroups: net.unix-wizards Subject: Re: Dual porting UDA50 drives under 4.2 Message-ID: <6911@brl-tgr.ARPA> Date: Wed, 2-Jan-85 14:21:05 EST Article-I.D.: brl-tgr.6911 Posted: Wed Jan 2 14:21:05 1985 Date-Received: Fri, 4-Jan-85 04:52:46 EST Sender: news@brl-tgr.ARPA Organization: Ballistic Research Lab Lines: 60 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 ----------