[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.63.0705061909290.19118@qynat.qvtvafvgr.pbz>
Date: Sun, 6 May 2007 19:13:51 -0700 (PDT)
From: David Lang <david.lang@...italinsight.com>
To: Pavel Machek <pavel@....cz>
cc: Nigel Cunningham <nigel@...el.suspend2.net>,
"Rafael J. Wysocki" <rjw@...k.pl>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Pekka J Enberg <penberg@...helsinki.fi>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: Back to the future.
On Thu, 3 May 2007, Pavel Machek wrote:
> Hi!
>
>> nobody is suggesting that you leave peocesses running
>> while you do the snapshot, what is being proposed is
>>
>> 1. pause userspace (prevent scheduling)
>> 2. make snapshot image of memory
>> 3. make mounted filesystems read-only (possibly with
>> snapshot/checkpoint)
>> 4. unpause
>> 5. save image (with full userspace available, including
>> network)
>
> Including network? Your tcp peers will be really confused, then, if
> you ACK packets then claim you did not get them. No, you do not want
> to start network.
anyone who is doing a hibernate or suspend who expect all the network
connections to be working afterwords is dreaming or smokeing something.
this is just another way that the failure can show up.
in fact, I would say that it would probalby be a nice thing to do for
intervening firewalls and external servers if a suspend closed all external TCP
connections rather then leaving them dangling (eating up resources until they
time out)
if you software can't tolorate the network connection going away on you it will
have problems in normal operation anyway, let alone when you suspend/hibernate
your machine.
David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists