Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!mp.cs.niu.edu!bennett From: bennett@mp.cs.niu.edu (Scott Bennett) Newsgroups: comp.periphs.scsi Subject: Re: Two HAs on single SCSI bus Message-ID: <1991Apr3.004833.20688@mp.cs.niu.edu> Date: 3 Apr 91 00:48:33 GMT References: <581@zds-ux.UUCP> <1991Apr1.232550.21460@mp.cs.niu.edu> <590@zds-ux.UUCP> Organization: Northern Illinois University Lines: 71 In article <590@zds-ux.UUCP> gerry@zds-ux.UUCP (Gerry Gleason) writes: >In article <1991Apr1.232550.21460@mp.cs.niu.edu> bennett@mp.cs.niu.edu (Scott Bennett) writes: >>In article <581@zds-ux.UUCP> gerry@zds-ux.UUCP (Gerry Gleason) writes: >>>In article <1991Mar31.190347.4360@netcom.COM> feustel@netcom.COM (David Feustel) writes: >>>> [text deleted --SJB] > >>The problem is usually that >>the hardware implementation is almost trivial, while the software design >>and implementation problem is almost intractable. Even IBM has never >>come up with a very reasonable version of it. The need, however, is >>*very* great. > >Don't you think "intractable" is rather strong? Of course, it all depends No, and I did say "almost." >and why you want to do it; some of the possible applications a quite >tractable. Say your goal is single-fault-tolerance, you can do this with >a pair of standard machines each with two controllers, one on each of two >SCSI busses, mirrored drives, etc. In this application, all you want to >do is switch from one initiator to the other, which is simple. If, on True and, if a human were fast enough, a human could make the changeover by hand. >the other hand, you want to share disks NFS style, it gets a bit more >complicated since the two initiators must coordinate their activities. I did mean sharing disks, but *not* NFS-style. NFS does *not* share disks. NFS has a server process running on a machine that has a disk dedicated to that machine and the server process can maintain integrity and, where necessary, serialization. There is no sharing involved with NFS. Shared disks, which I thought the earlier writer was refering to, pose a very difficult set of *software* problems, though the hardware problems aren't usually that bad. >This "lack of well defined feature set" issue probably means that it will >remain on the "linatic fringe", at least for a while, although it would >be nice if some of the controler/driver suppliers would at least provide >some hooks for integrators/developers to implement their own support. In fact, we use something like it in a few cases on our Amdahl 5890-300, which is running three domains. However, the support provided by MVS/XA is not exactly wonderful at making it easy for the problem program to maintain data integrity in shared files. I guess it has some way of keeping the VTOC from turning to spaghetti, but the data in the files aren't well protected by the system. The application has to have its own protocol for keeping its data intact. The security system we use in each of the three domains (ACF2) is an example of how one developer handled the problem. And a developer has the advantage of knowing the limited set of conditions that must be protected against, whereas the operating system writers have to provide protection against a much wider, more general set of conditions. 3390-style disks obviously are not SCSI, but I've not yet heard of any vendor providing such support for shared SCSI disks at all. > >Gerry Gleason Scott Bennett, Comm. ASMELG, CFIAG Systems Programming Northern Illinois University DeKalb, Illinois 60115 ********************************************************************** * Internet: bennett@cs.niu.edu * * BITNET: A01SJB1@NIU * *--------------------------------------------------------------------* * "Well, I don't know, but I've been told, in the heat of the sun * * a man died of cold..." Oakland, 19 Feb. 1991, first time since * * 25 Sept. 1970!!! Yippee!!!! Wondering what's NeXT... :-) * **********************************************************************