Re: Back to the future.

David Lang
2007-04-28T19:05:45Z

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1902 bytes --]

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