Re: Back to the future.
From: David Lang
Date: Sat Apr 28 2007 - 15:06:02 EST
On Sat, 28 Apr 2007, Oliver Neukum wrote:
Am Samstag, 28. April 2007 01:50 schrieb David Lang:
3. make mounted filesystems read-only (possibly with snapshot/checkpoint)
4. unpause
5. save image (with full userspace available, including network)
6. shutdown system (throw away all userspace memory, no need to do graceful
shutdown or nice kill signals, revert filesystem to snapshot/checkpoint if
needed)
And then you'll have people wonder why the server which sent out all
those files has no log entries. You'd have to selectively unfreeze user
space, which is a cure worse than the desease.
Simply throwing away user space work is a bug. And no, you cannot say that
it'll be redone away, as you are throwing away accepted input, too.
when you are doing a suspend-to-disk I disagree with you. whoever is doing the
suspend knows what is going on, and they can decide what needs to be done.
the only case where you have 'unexpected' work being thrown away is if you are
suspending a network server, and the process of suspending it is going to cut
all the network connections anyway so it's not a seamless process. In this case
it's fair to let the sysadmin choose between loosing some logs or doing some
other step to prevent this from happening (which could be to shutdown the
network service, or load a iptables rule to block the service)
however, most of the uses of suspend-to-disk are going to be single-user
machines and in that case telling the user that anything that they do after
issuing the suspend is going to be lost is a perfectly sane thing to do.
and for that matter, if the snapshot is cheap enough, some people may choose to
cron the snapshot portion of a suspend-to-disk evvery few min as a safety net
for something going wrong. In this case they really do want all of userspace to
keep working after the snapshot.
David Lang