sob@soma.bcm.tmc.edu (Stan Barber) (11/03/86)
RTU 3.0 is somewhat different from RTU 2.2A. Some changes are unnoticed by most users. Sometimes, Masscomp points up these changes in the release notes and othertimes, you have to find it out for yourself. One of these changes is in the use of /etc/fstab in place of /etc/checklist. Under RTU 2.2A, you placed a list of all the disk devices you wanted /etc/fsck to check on boot in /etc/checklist. This would cause all filesystems to be check following a crash (A GOOD thing to do!). Now, to get this to occur under 3.0, you must do a similiar thing in /etc/fstab. It is not quite the same format, but the format is covered in FSTAB(5) in the manual. Unfortunately, the system management guide(s) do not discuss this at all.
amen@quequeg.bcm.tmc.edu (11/05/86)
And here are two others that I found (and have submitted SQR's for): 1) Swap files and the system resource map (SQR #2506) If one builds a system with more than one but fewer than four swap files configured, the system will run out of resource map space at boot. This _seems_ to only occur on the SMD (XMD) disk and _if_ the swap file is _greater_than_ 6MB (6MB was OK, 14 was not). (I believe the driver for the DSD disk requires less system resource map space.) The error that appears on the console is "rmap overflow xxxxx" where xxxxx is a number signifying where the overflow occured. The answer I got back from Masscomp was rather mealy-mouthed. They did explain why the overflow occurs (but not why it should occur for 14 but not 6MB nor why it occured with all relevant parameters set to the defaults). The text of the reply (edited): Because of the way RTU sizes the swapmap, it is possible in some instances to get swapmap (sic) overflow error messages on the console terminal when the system boots. Note that if this occurs the system is functional but is not able to use the existing swap space. The swapmap is sized according to: The number of swap files configured (nswapdev) The maximum number of processes configured (nprocs) The higher the values, the larger the allocated swapmap. The swapmap required is also affected by the dmmax parameter. Since the swapmap is partitioned into chunks of the size of dmmax, smaller dmmax values require a larger swapmap because there are more, smaller, chunks of swap space to manage. The current method of allocating swap files is reasonably accurate if the default values for the parameters dmmax and nprocs in /etc/master are used, and if the system is allowed to determine the swap file size as described in the System Management Guide (Chapter 3). [Note: All of the above held true on my system...I did not change dmmax _or_ nprocs...only nswapdev (to 2)! Also...the System Management Guide _does_not_ mention _either_ nprocs _or_ dmmax! It does mention procs in Appendix D, I assume this is what is meant by nprocs.] [deleted weird example] Should a swapmap overflow occur, the work around is to increase any or all of the above mentioned parameters. The recommended values are: nprocs 100 dmmax 1024 nswapdev 10 should overflows still occur, increase the value of dmmax to 2048 or more. Future development plans may do away with the concept of swapmaps, thereby solving the problem. [Here's the part I like :-)] For more information about swaping and parameters that affect swapping, please refer to your System Management Guide and the RTU Programming Manual. End of SQR #2506 response. Part of the reason for submitting an SQR was to get Masscomp to put more in the System Management Guide about these parameters. The section in Chapter 3 only discuses nswapdev and neither the section on the configuration file or the appendix mentions dmmax. 2) dpe and mkfs When creating partitions on a DSD drive the system must be rebooted before mkfs will recognize the devices. This is not stated in the System Management Guide. This again has to do with the particulars of the DSD device driver. For those of you saying "but did you mknod the new devices before trying mkfs?" YES, YES, YES OF COURSE I DID! 3) A related matter: What ever happened to the proposal for electronic (uucp) submission of SQR's? (Stan?) As I recall from the last MUS meeting Praveen was going to make up a skeleton form and e-mail it to all of us...I know Praveen is pretty busy but he is alive! [ mod response-- Thanks for reminding me. I will see what headway I can make in this area. I have just be Sooooo busy..... -sob] Sorry this is so long but I thought these might be useful and I hope that only one of us has to learn a thing the hard way. Bob Amen USPS: Chesapeake Bay Institute/Johns Hopkins University The Rotunda, Suite 315 711 W. 40th St. Baltimore, MD 21211 Voice: +1 301 338-6329 UUCP: seismo!-\ >umcp-cs!\ allegra!/ \ >aplcen!quequeg!amen decvax!decuac!-----/ BIX: bamen (very infrequent)