linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* resume from hibernation without touching saved image?
@ 2014-10-31 12:00 Michael Tokarev
  2014-10-31 23:00 ` Rafael J. Wysocki
  0 siblings, 1 reply; 3+ messages in thread
From: Michael Tokarev @ 2014-10-31 12:00 UTC (permalink / raw)
  To: linux-pm

Hello again.

Currently, linux kernel is able to resume from a previously saved
image, and it basically clears up that image when done, so there's
no way to resume from it once more.

Is it possible to _not_ touch the image at all and keep it in the
same state as before?  Maybe putting it to a readonly block device
(like blockdev --setro, or mdadm readonly array) will help?

What I'm thinking is to speed up starting of a diskless client which
boots out of read-only filesystem - the only thing it needs to do is
to start X server and connect to a terminal server, but booting it
to the point when it can do that requires some time.  So I'm thinking
about booting it there and suspending it, so it can be resumed later,
so the only thing left is just to start X.  That works, but the prob
is that it works only once.

So, basically, how to turn off that feature which resets the saved
hibernation image at the end of resume process?

Thanks,

/mjt

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: resume from hibernation without touching saved image?
  2014-10-31 12:00 resume from hibernation without touching saved image? Michael Tokarev
@ 2014-10-31 23:00 ` Rafael J. Wysocki
  2014-11-01  5:16   ` Michael Tokarev
  0 siblings, 1 reply; 3+ messages in thread
From: Rafael J. Wysocki @ 2014-10-31 23:00 UTC (permalink / raw)
  To: Michael Tokarev; +Cc: linux-pm

On Friday, October 31, 2014 03:00:26 PM Michael Tokarev wrote:
> Hello again.
> 
> Currently, linux kernel is able to resume from a previously saved
> image, and it basically clears up that image when done, so there's
> no way to resume from it once more.

Which is intentional.

> Is it possible to _not_ touch the image at all and keep it in the
> same state as before?  Maybe putting it to a readonly block device
> (like blockdev --setro, or mdadm readonly array) will help?

Keeping an image itself immutable doesn't help, because the state
recorded in the image has to match the state recorded in other
places, like fs superblocks and such.

As long as you can't guarantee that all of that is in sync, nothing helps.

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: resume from hibernation without touching saved image?
  2014-10-31 23:00 ` Rafael J. Wysocki
@ 2014-11-01  5:16   ` Michael Tokarev
  0 siblings, 0 replies; 3+ messages in thread
From: Michael Tokarev @ 2014-11-01  5:16 UTC (permalink / raw)
  To: Rafael J. Wysocki; +Cc: linux-pm

01.11.2014 02:00, Rafael J. Wysocki wrote:
> On Friday, October 31, 2014 03:00:26 PM Michael Tokarev wrote:
>> Hello again.
>>
>> Currently, linux kernel is able to resume from a previously saved
>> image, and it basically clears up that image when done, so there's
>> no way to resume from it once more.
> 
> Which is intentional.

Sure, I understand.

>> Is it possible to _not_ touch the image at all and keep it in the
>> same state as before?  Maybe putting it to a readonly block device
>> (like blockdev --setro, or mdadm readonly array) will help?
> 
> Keeping an image itself immutable doesn't help, because the state
> recorded in the image has to match the state recorded in other
> places, like fs superblocks and such.

As I mentioned before, all the filesystems are readonly so does not
change no matter how many times you resume, and there's no other state.

The only thing that changes is the swap/image and its signature -- it
can't be made read-only because it must be read-only for the kernel
which is being resumed, but it's impossible since it is the kernel who
writes this image to start with.

> As long as you can't guarantee that all of that is in sync, nothing helps.

No one can guarantee this - eg, usb devices might be removed or added
while the system is sleeping, and so on.

In my case it is easy to guarantee there's no state changes, because
there really aren't.  But ofcourse this is a rather rare situation.

Thanks,

/mjt


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2014-11-01  5:16 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-10-31 12:00 resume from hibernation without touching saved image? Michael Tokarev
2014-10-31 23:00 ` Rafael J. Wysocki
2014-11-01  5:16   ` Michael Tokarev

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).