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