CLAYTON@XRT.UPENN.EDU ("Clayton, Paul D.") (06/20/88)
Kees Noyens, from the Netherlands, asks the following question about the use of RD53 disks on a boot node in a LAVC. > On the very first page of the VMS Local Area VAXcluster manual is stated > that a Microvax II bootnode must have a RD54 or larger system disk. > And the VMS 4.6 KITINSTAL.COM refuses to install VMS 4.6 on a RD52 or RD53 > system disk if the Microvax II is a LAVC bootnode. > Why ? Is it just a performance issue, is it just Digital trying to sell more > expensive disk-units or is there a serious reason like Satellite nodes > not being able to boot from a remote RD53 ? > Any comments on or experiences with Microvax/RD53 serving as LAVC bootnode > are welcome. The issue does appear to be one of selling more, and larger, disks to the public but there are some items to be considered. One of the assumptions that is made with a LAVC is that the boot node will have to support the satellite nodes for page/swap space, the accounting files, the Operator logs, and the job queue manager files. This by definition can use a considerable amount of room. One the MAIN tasks to perform as a cluster manager, either CI or NI, is to keep the system disk(s) clean and with sufficient (read LARGE) amounts of free disk space. Installing 4.6 or for that matter 5.0 on a RD53 leaves VERY LITTLE room when the above files are then added in. I therefore consider the 'locking' out of RD53 systems as boot nodes as a means to try and keep users from getting themselves into a bind that is tough to get out of. I once had my system disk, that supported 4 CPU's (785's to 8700's), become suddenly empty of free blocks and the resulting problems are the things nightmares are made of. The type of nightmare when you wake up in a total sweat and the room is 60 degrees. In my case we ended shutting the cluster down and going at the disk to clean it up before the user community came back on-line. If you still want to install it anyway, you can copy the entire installation kit down to disk, on a remote system, then extract the KITINSTAL.COM file from the xxx.A save set. This file would then be edited to go around the part where is stops the installation if a RD53 is detected. Then the rest of the xxx.A save set would be dumped down to a local directory, and the new KITINSTAL.COM file copied into this directory, effectively overwriting the delivered version. The next step would be to create a new xxx.A save set in the same place that the xxx.B and .C (and so forth) are located consisting of all the oringinal files plus the new KITINSTAL.COM file. The installation can then be done using the DECnet abilities of VMSINSTAL.COM and specifing the directory the save sets are located in. DO NOT CALL DEC IF YOU HAVE ANY PROBLEMS IN DOING THIS. YOU ARE ON YOUR OWN!!!! This is what is known as 'unsupported', and they do not want to be involved in solving any resulting problems. Have fun.!! :-) pdc Paul D. Clayton Address - CLAYTON%XRT@CIS.UPENN.EDU Disclaimer: All thoughts and statements here are my own and NOT those of my employer, and are also not based on, or contain, restricted information.