On Tue, 20 Jun 2000 10:27:08 +0300  Maxim Sobolev wrote:
 | Mike Smith wrote:
 | > The real issue here is persistent system state across the S4 suspend; ie.
 | > leaving applications open, etc.  IMO this isn't really something worth a
 | > lot of effort to us, and it has a lot of additional complications for a
 | > "server-class" operating system in that you have to worry about network
 | > connections from other systems, not just _to_ other systems.
 | Why then brand commercial vendors have such capability in their
 | "server-class" operating system for a long time? Particularly HP's PA-RISC
 | servers does have it, at least I remember such feature in the old 30MHz
 | systems which I managed several years ago (the systems was shipped with
 | small internal battery, which in the case of power
 | failure was used to dump system to the disk).
 | -Maxim.

On very old systems with ferrite core memory the whole "core" simply
retained whatever was running at the time of a power out.  When
power was restored the program just started ticking from where it
left off with no loss of state.   Later attempts at preserving
"core" state over power out involved batteries for memory, processor
registers and for peripheral buffers.  As buffer sizes in controllers
grew and processor memory became more volatile it became harder
and harder to simply recover that way.  The system always came up
from bootstrap and never attempted to automatically recover to a
previously running system state.  These days we tend to think of
a "core dump" as a diagnostic tool and not as a state image to be
recovered as a part of powering up the computer.  But does it have
to be that way?

Perhaps I am nieve but it seems to me that many "server class"
systems could make great use of a hibernation mode which would
allow the system to be suspended to wait for some critical event
to pass and then to start running exactly as they were at the time
of the suspend signal.  At worst this could only minimize the
recovery time experienced by the server.

    Chris Fedde
    303 773 9134

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to