freezing system state

[Robert G. Brown]

On Thu, 14 Sep 2000, Eugene Leitl wrote:

> 
> Can anyone point me towards information how I can snapshot the entire
> system state to hard drive, and have an option to restore it at boot
> time?
> 
> If Linux can't do that yet, are there plans for putting support for
> suspend state into it?

This works for laptops already, so linux supports it to at least that
extent.  I >>think<< that special laptop bios calls are involved, and on
my laptop at least one has to set up a special disk partition for the
memory/state dump.  I haven't looked at the kernel source to see whether
or not anything like this exists in regular kernels without bios support
-- I rather think not (for reasons given below).  A good question for
the kernel list.

Other nonlinear possibilities for accomplishing this might be a
variation of "two-kernel monte" from scyld (?) or e.g. vmware.

Note that "the entire system state" isn't necessarily something that can
be stored or saved -- only the "Markovian" (history independent,
instantaneous) component of the state can be saved, unless the kernel
itself is VERY state aware and intelligent.  Device initialization is
typically NON-Markovian.  So a snapshot restore will generally not bring
a network device or a CD-player or SCSI card or anything else that has
been moved out of the default power-on state by means of a handshaking
interaction or download of BIOS back into the same state it was in at
powerdown time (without a VERY SMART snapshot program and device-state
aware kernel). Devices that are indeed in a different state from that
presumed by the "saved" kernel image can crash the system almost
immediately or cause other, lesser problems.

On my laptop I generally don't crash, but if I do a suspend at Duke
(attached to one network) and restore at home (attached to a different
network with a different, e.g. IP number) the network, at least, is
broken (all sockets, NFS mounts, and so forth included) and must be
restarted.  From the little I've done with e.g.  Adaptec SCSI adapters
(which generally require this big chunk of very picky code to be
downloaded to the adapter at boot time, followed by a very precise set
of initialization instructions that match the kernel configuration with
regard to e.g. reset delays and tagged queue depth) I'd expect this to
be all but impossible on SCSI equipped systems that reset the adapter
from the power-on state.  IDE and IDE-ATAPI seems to work well enough;
they are presumably less state-sensitive, although I'd bet that
IDE-ATAPI CDR's (with a scsi interface) get bollixed up.

It's usually easier to just write your application(s) to accept a
user-defined signal and do a checkpoint/suspend, but in the case of e.g.
PVM applications even THAT is not likely to work without a lot of effort
because reconstruction and restarting of the running calculation again
requires configuring the virtual machine, which is basically
non-Markovian (at least with respect to the running program images).  A
"restart" from saved data is then going to be easier than a "resume"
from anything like an actual image.  Imagine trying to restart from
suspend/crash just one PVM client while the others continued in the
calculation (something I've tried to arrange a time or two in the past).
It can be done but it is non-trivial.

A tough problem.  I'm curious to see if any more recent work has been
done on it in other answers to your question.

     rgb

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu