johnk@opel.COM (John Kennedy) (03/18/91)
Are there any SCSI implementations available that allows use of two host adapters on a single bus? Specifically, I want to dual-port a disk drive by such a configuration as this: ____________ ____________ | | | | | | | | | CPU A | SCSI bus | CPU B | | |================================| | |____________| || |____________| ____ (____) |disk| |____| Is this what differential SCSI is? Is there any good published material on the subject? The goal is to have two redundant CPUs able to access the same data (not necessarily at the same time, but that would be great). I'm open to any advice. Thanks, John -- John Kennedy johnk@opel.COM Second Source, Inc. Annapolis, MD
david@talgras.UUCP (David Hoopes) (03/21/91)
In article <55@opel.COM> johnk@opel.COM (John Kennedy) writes: >Are there any SCSI implementations available that allows use of two >host adapters on a single bus? Specifically, I want to dual-port >a disk drive by such a configuration as this: > There are commands in the scsi spec to allow this to work. However I have never seen it done. In Therory you could use the same set up to network the two cpu's together. We have talked about doing a scsi network (just for fun) but we have not had time. All of the existing drivers that I have seen specificly exclude this kind of operation. good luck. -- --------------------------------------------------------------------- David Hoopes Tallgras Technologies Inc. uunet!talgras!david 11100 W 82nd St. Voice: (913) 492-6002 x323 Lenexa, Ks 66214
burke@seachg.uucp (Michael Burke) (03/28/91)
In article <55@opel.COM> johnk@opel.COM (John Kennedy) writes: >Are there any SCSI implementations available that allows use of two >host adapters on a single bus? Specifically, I want to dual-port >a disk drive by such a configuration as this: > > > ____________ ____________ >| | | | >| | | | >| CPU A | SCSI bus | CPU B | >| |================================| | >|____________| || |____________| > ____ > (____) > |disk| > |____| > >Is this what differential SCSI is? Is there any good published material on >the subject? > >The goal is to have two redundant CPUs able to access the same data (not >necessarily at the same time, but that would be great). > >-- >John Kennedy johnk@opel.COM >Second Source, Inc. >Annapolis, MD Yes, one can configure a SCSI channel as above. A problem may occur if the two hosts try to access the data at the same time (in Unix each host "owns" the super block). Even in this situation you can get around the problem by having two partitions, each host "owning" one partition. We have at least one customer who has a similar configuration, ie two hosts with one disk drive and several SCSI tape drives shared. Both SE and DIFF SCSI support this type of connection. -- --- Michael Burke Sea Change Corporation 6695 Millcreek Drive, Unit 8 Mississauga, Ontario, Canada L5N 5R8 Tel: 416-542-9484 Fax: 416-542-9479 UUCP: ...!uunet!attcan!seachg!burke
feustel@netcom.COM (David Feustel) (04/01/91)
I tried to do this with 2 Adaptek 1542a controllers and a Connor 100meg SCSI drive. Wouldn't work. Adaptek was absolutely unresponsive when I sought help. -- David Feustel, 1930 Curdes Ave, Fort Wayne, IN 46805, (219) 482-9631 EMAIL: netcom.com
gerry@zds-ux.UUCP (Gerry Gleason) (04/02/91)
In article <1991Mar31.190347.4360@netcom.COM> feustel@netcom.COM (David Feustel) writes: >I tried to do this with 2 Adaptek 1542a controllers and a Connor >100meg SCSI drive. Wouldn't work. Adaptek was absolutely unresponsive >when I sought help. I'm not surprised. This is not something you just go ahead and do, it requires drivers on both machines that support it. I don't think there are any standard drivers that support this, but I'm sure it's been done. RTFM! If you don't find anything about "dual-initiators" or "dual-hosts", in the driver documentation, then it probably doesn't support it. This is a lunitic fringe feature; not very common. Gerry Gleason
neese@adaptx1.UUCP (04/02/91)
>I tried to do this with 2 Adaptek 1542a controllers and a Connor >100meg SCSI drive. Wouldn't work. Adaptek was absolutely unresponsive >when I sought help. The A board did not take into account this scenario. The B board should work fine in this environment. Although, if this is the CP3100, there may be other problems. I have had many reports about the CP3100 not coexisting with other devices very well, causing hangups on the SCSI bus. One thing to be aware of,...you must change the ID of one of the adapters. By default they are set to 7. Should set one of them to 6. Roy Neese Adaptec Senior SCSI Applications Engineer UUCP @ neese@adaptex uunet!cs.utexas.edu!utacfd!merch!adaptex!neese
bennett@mp.cs.niu.edu (Scott Bennett) (04/02/91)
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] > >This is a lunitic fringe feature; not very common. I'm not quite sure what your point is in making this remark. If by "lunitic[sic] fringe feature" you mean that a) it is one that is not often supported in SCSI (or anywhere else, for that matter) and/or b) you'd have to be nuts to use a feature that is so poorly (in most cases) supported, then your comment is more or less correct. However, if you mean that c) there is little use for such a feature and/or d) you'd have to be nuts to want the functionality that such a feature *ought* to provide, then you are clearly out of touch with how a vast portion of computer systems work and are used. 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. > >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... :-) * **********************************************************************
gerry@zds-ux.UUCP (Gerry Gleason) (04/03/91)
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] >>This is a lunitic fringe feature; not very common. > I'm not quite sure what your point is in making this remark. If >by "lunitic[sic] fringe feature" you mean that a) it is one that is not >often supported in SCSI (or anywhere else, for that matter) and/or b) >you'd have to be nuts to use a feature that is so poorly (in most cases) >supported, then your comment is more or less correct. However, if you >mean that c) there is little use for such a feature and/or d) you'd >have to be nuts to want the functionality that such a feature *ought* >to provide, then you are clearly out of touch with how a vast portion >of computer systems work and are used. Sorry, I didn't mean to attack the sanity of those who might want such a feature, but just what you said in a) and/or b). Actually c) is not that far off either, if a substantial number of users have a need for the feature, it would be available (doesn't have to be big percentages either, 10-20%). The fact that nobody has offered a pointer to somebody doing it is pretty good evidence that the number that *must* have it is vanishingly small. >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 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 the other hand, you want to share disks NFS style, it gets a bit more complicated since the two initiators must coordinate their activities. 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. Gerry Gleason
bennett@mp.cs.niu.edu (Scott Bennett) (04/03/91)
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... :-) * **********************************************************************
yuping@auspex.auspex.com (YuPing Cheng) (04/04/91)
In article <1991Mar27.175719.3474@seachg.uucp> burke@seachg.UUCP (Michael Burke) writes: >Yes, one can configure a SCSI channel as above. A problem may occur if the >two hosts try to access the data at the same time (in Unix each host "owns" >the super block). Even in this situation you can get around the problem >by having two partitions, each host "owning" one partition. > SCSI provides RESERVE and RELEASE commands to allow one host to own the disk drive temporarily when disk data are updated. What happen when one host reserves the drive and never releases it. This is an application problem. :-) Yu-Ping Cheng, Auspex Systems Inc., ycheng@auspex.com
gerry@zds-ux.UUCP (Gerry Gleason) (04/05/91)
In article <1991Apr3.004833.20688@mp.cs.niu.edu> bennett@mp.cs.niu.edu (Scott Bennett) writes: >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: >>Don't you think "intractable" is rather strong? Of course, it all depends > No, and I did say "almost." I guess I disagree. It is true that there are a lot of possible approaches to the problem, many of which are intractable, but there are clean solutions if you really need this. >>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. What's your point, that this is a trivial use of the capability? Not for people who want this. >>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. I'm not sure any more if the original posting just asked about two initiators or sharing disks, nor did I intend to produce an exhaustive list of applications. Further, from an application perspective their is not really an important difference between "NFS-style" and the type of disk sharing you are talking about. Performance, yes, but functionally, not really, particularly if you ignore details like the two machines having different view and privledges on the shared disk (really a feature that give more capability, not less). I'm saying your distinction is implementational, not functional. > 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. [ ... ] Sounds like they chose one of the intractable aproaches. Gerry Gleason