Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU Path: utzoo!decvax!bellcore!petrus!sabre!zeta!epsilon!gamma!ulysses!ucbvax!info-vax From: info-vax@ucbvax.UUCP Newsgroups: mod.computers.vax Subject: Re: Need system with 180 users accessing 1 database Message-ID: <8512092136.AA09248@sivax.UUCP> Date: Mon, 9-Dec-85 16:36:09 EST Article-I.D.: sivax.8512092136.AA09248 Posted: Mon Dec 9 16:36:09 1985 Date-Received: Fri, 13-Dec-85 19:56:50 EST References: <8512040230.AA25049@nyu.arpa> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 181 Approved: info-vax@sri-kl.arpa I know little about IBM mainframes, but here is a solution to the problem for VAX or PDP-11 users. Rather than buy a more expensive processor, one solution is to add one or more similar processors to the same system. This, however, introduces a further problem. All processors in the configuration must share the same database if they are to appear (from a user or application program's point of view) as a single system. System Industries (Milpitas, California) has a controller (the 9920) that allows multiple CPUs to access a single disk storage device. However, unless there is some form of communication between the CPUs, it would be difficult (!!) to maintain the data integrity on the disk. POSSIBLE SOLUTIONS: LAN METHOD: The following figure shows that all requests for access to the common disk are processed by a single CPU on the LAN. This CPU treats all service requests simply as another local user. This provides a limited increase in processing power because each sattelite CPU can handle its own front end processing. BUT, the single CPU still has to handle all disk access requests which can create quite a bottleneck. +--------------------------------------+ | network | +--------------------------------------+ | | | +--------+ +----------+ +---------+ | cpu a | | cpu b | | cpu c | +--------+ +----------+ +---------+ | +----------------+ | controller | +----------------+ | +-----------------+ | common database | | disk | +-----------------+ While networks are useful for remote access, they introduce an overhead in both CPU time and I/O throughput. They provide only a limited degree of system integration and need special prorocols to access the data. File transfers may also have to pass over other hosts before reaching their destination. As a rule, it's not worth the cost to use a network to merely access a file system. MULTI PORTED CONTROLLER SOLUTION: The next figure shows a dual port controller configuration. Two CPUs are connected to a dual ported controller which in turn is directly connected to the disk. +----------------+ +------------------+ | cpu a | | cpu b | +----------------+ +------------------+ | | +-----+ +----+ | | +-------+--------------+-----------+ | controller | +----------------------------------+ | +--------------------+ | disk | +--------------------+ This configuration is fine except that it is possible for two CPUs to have write access to the disk and neither will know of the modifications the other is making to it. CPU A could allocate a block to one file and CPU B could allocate the same block to an entirely different file. This of course would corrupt the volume's structure. THE SIMACS SOLUTION from System Industries: In a situation like the one in the last illustration, the System Industries 9920 controller can define one semaphore for each CPU. If the semaphore is not set, any CPU can request that the controller set it. The controller does this and remembers which CPU made the request, and refuses requests from any other CPU until the semaphore is released. By agreement between cooperating programs, the semaphore gives each CPU exclusive access to the disk structure for the period of time that the CPU owns the semaphore. During this time, critical updates to the disk structure can be protected, and yet shared access for OTHER disk I/O's that do NOT alter disk structure is still allowed. The controller also allows one CPU to RESERVE the semaphore for its use. The controller will inform any other CPU requestor that the semaphore is already in use, and will inform the owner that a request has been made. Thus, the owner CPU can release the disk for others to use. It is necessary to make modifications to the operating system software to ensure that the disk structure is left in an integral state before ownership of the semaphore is relinquished. It is also essential for the CPUs to cooperate with each other, since the controller does not physically lock out or prevent other CPUs from accessing the reserved data. In UNIX OS's, the kernal in each CPU makes sure it owns the sempahore before performing any I/O operations which could be vulnerable to the actions of another CPU, or which could corrupt another CPUs disk structure. Before relinquishing the semaphore, a CPU makes sure that it has written the altered buffers, the inodes and superblocks to the disk. After regaining ownership of the semaphore, it checks to see if the superblock shows a new version number (thus indicating that another CPU has made changes to the disk). If so, it refreshes buffers, in-core inodes etc. BSD 4.2 SIMACS must also flush and refresh the cylinder group information summary and the disk quota information if the QUOTA option has been selected at configuration time. UNIX OS kernal has no central place to put the logic that controls the reserve and release of the semaphore. Instead, SIMACS contains two routines called sirelease() and sireserve(). SIMACS brackets critical code anywhere in the kernal with calls to these routines. As a general rule, a CPU must own the semaphore before the kernal locks an inode, and may release the semaphore after unlocking the inode. Also, the kernal must own the semaphore in other critical places before making reference to an inode or superblock. FILE LOCKING IN SIMACS: Althoug UNIX allows more than one user to open a file for write, SIMACS provides file locking as an option. If the System Manager has not selected file locking, simultaneous reading and writing is allowed. Simultaneous processes writing to a file must cooperate with one another to maintian data integrity. But, with file locking selected: - If a regular file is opened for read, SIMACS allows any number of other readers to have read access, but denies access to writers. - If a regular file is open for write or read/write, SIMACS allows no other reader OR writer to have access. ALL CPUs on a SIMACS system must be consistent in this respect. That is, either ALL must select file locking, or NONE may select file locking. Normally, alll this is transparent to the users. If a user tries to open a locked file, the SIMACS software will wait until the file is available, and then open it. Or, a no-delay option can be specified, which will return an error status if a process tries to open a locked file. This little dissertaion on SIMACS barely scratches the surface on the features and capabilities of the system. What it boils down to in a sentence is: You can have up to eight CPUs channeled through one controller to one data disk that is shared by ALL, and maintain volume and data integrity for all read and write operations. Phew. If you want more info on this, don't send mail..I won't get it. (I'm working on it). Instead, the person to talk to at System Industries is Dr. Paul Ramsay (UNIX) or Dr. Albert Chu (VMS). Their number is (408) 942-1212. Please feel free to leave any comments, messages or questions for me as a public message....as I said...I can't receive mail here (no one can). Good luck... Jim Bauman System Industries (sivax)