Various kinds of System reloads 2362

for cp67 & vm370 the "spool file system" .... basically emulated unit record information was subject to cold and warm start ... and then chkpt start was later added.

part of booting the system including bringing up the spool file system ... and was prerequisite to the system coming up .... so it had to come up. in part, the "spool file" disk area tended to be shared between spool files and dynamic virtual memory paging. if the area wasn't initialized and available ... you also didn't have paging ... integral to the operation of the system.

oiriginally a cold start was that it initialized the area to completely empty (all existing data was lost). warm shtudown would write in-storage allocation information to disk at shutdown typicalland on boot, this information would be reread back into memory. on things like power-failure ... the system went down w-o having written the warm start information and had to come up cold. cp67 also added automatic creation of a "dump file" (in the system spool area) on a kernel crash ... and then automatic reboot (kernel failure, dump, save warm data, reboot, and warm start could be done in a minute or two.

there is this story about somebody at mit making a kernel change to one of their systems in an i-o driver and having 26 system crashes and reboots in the course of the day. the story is that this prompted some improvements in multics ... since multics at the time supposedly might take an hr or so to come back up after a crash . part of this was that the cp67 & vm370 stuff was done at the science center on 4th flr of 545 tech sq

and multics was being done on the 5th floor.

to handle the power failure case, chkpt start was added. during normal operation, a very abbreviated vesion of some in-storage control information was written to disk. if reboot selected chkpt start ... boot would read the abbreviated information and then use that to reread the spool area to recreate the rest of the information. this was somewhat analogous to fsck since the reread-reconstruct could take an hr for a spool system with a large number of files.

the automatic reboot would bring the system back to the point where users could log back in. however, over the years, lots of automated processes were added to normal operating environment ... and these required manual initialization.

for the automated benchmarking process, mention in recent post

i had added a boot process that could be used to start up these automated processes at boot as part of normal production operation. the purpose for automated benchmark

was to allow rebooting between the automated benchmarking ... to have a clean, fresh startup between each benchmark. the automated benchmarking could run for days unattended ... with automated reboot and starting each new benchmark.

this feature was incorporated in standard released system and is now part of standard production vm operation.

later doing some high-speed networking support as part of hsdt

i did "spool file system" rewrite ... recent lengthy post discussing characteristics of sfs rewrite

it was primarily to significantly improve the performance ... but while i was at it ... i changed the paradigm so that spool areas could be added & removed during normal operation (w-o rebooting the system). this had the side-effect that even if chkpt-like start was required .... the system reboot didn't have to be delayed until it finished (i also redid how the chkpt operation was implemented so that it was significantly quicker).