OC.TREI@CU20B.COLUMBIA.EDU (Peter G. Trei) (02/09/86)
Several months ago, mention was made on this mailing list of an undocumented RAM disk built into VMS (apparently so a system could be brought up for diagnostics without disks). Some people at my company are now intensely interested in this, and of course I did not keep copies of that traffic. So: - Where in the fiche (we are using version 4.1/4.2) do I look? - Has anyone been using it successfully? - Anyone know if it is likely to suddenly vanish in the next update? Send the replies to me directly (oc.trei@cu20b.arpa) or to the whole list as you see fit. thanks in advance, Peter Trei oc.trei@cu20b.arpa [anyone who associates my opinions with those of my employer is a naive fool] -------
JCV@CERNVM.BITNET.UUCP (02/14/87)
Let's get some things straitened out about the VAX RAM disk which has been the subject of so much talk lately. This has nothing to do with the usual RAM disks of PCs etc, which have more memory in RAM than on disk and slow disk access speeds. It would of course be madness to use such a thing on a VAX during usual operations. To save disk I/Os on frequently used images, as somebody suggested, VMS has the feature of global sections (images installed /SHARED); you can see this effect by looking at the global valid fault rate (in MONITOR). However, there is one situation in which you would like to be able to run the system without a system disk: when running standalone backup. Usually, BACKUP will page to what it thinks is a system disk, but really is either the console device (floppy or TU58) or, on uVAXes, a TK50. In latter case, in fact, it just CANNOT page - so a way out has to be found. And this way out consists of using a part of nonpaged pool as a RAM disk, which is loaded during system startup, and turning off system paging (via a SYSGEN parameter). The whole mechanism is explained in the comments contained in - yes, you guessed right - SYS$UPDATE:STABACKIT.COM. And, well - it even contains in-line the 40-line MACRO programm to initialize the disk to a specified size of blocks (pool permitting)! So, as you can see, it pays to have a look at the stuff DEC supplies you with every system! We will try another application of this nice feature in the future: Every single-disk 750 user has the problem of waiting at least one hour till standalone BACKUP has started from the TU58s if you want to restore your disk (to remove fragmentation). It should be possible to build a TK50-like kit on your disk which you can boot in a few seconds and then use it to overwrite just that disk! --- Jan Vorbrueggen
carl@CITHEX.CALTECH.EDU.UUCP (02/14/87)
> We will try another application of this nice feature in the future: Every > single-disk 750 user has the problem of waiting at least one hour till > standalone BACKUP has started from the TU58s if you want to restore your > disk (to remove fragmentation). It should be possible to build a TK50-like > kit on your disk which you can boot in a few seconds and then use it to > overwrite just that disk! No, you can't build a TK50-like kit on your disk (the TK50 kit contains code to copy from TAPE to memory, doesn't know anything about disk structure until VMS is running, etc. What you really want to do is build a STANDALONE BACKUP kit on your disk that looks like regular VMS except that what it runs at startup time is the VMS kernel with STANDALONE BACKUP (STABACKUP) instead of full VMS. This doesn't use RAM disk, it uses real disk, then turns off paging. (And besides, the disk space it uses is a small fraction of the storage space required for the TU80/TK50 kits.