Re: Re: standby to disk transition

[Nigel Cunningham <nigel@suspend2.net>]

[-- Attachment #1.1: Type: text/plain, Size: 1685 bytes --]

Hi Dave.

On Tuesday 14 March 2006 07:28, Dave Jones wrote:
> On Mon, Mar 13, 2006 at 10:24:20PM +0100, Pavel Machek wrote:
>  > > if suspend-to-disk is fast enough, you could just *always* write
>  > > to disk, even if we're doing S3.  If power runs out, you then have a
>  > > valid resume image on-disk.  iirc, this is what Windows does.
>  >
>  > Yep, I call that suspend-to-both. It is planned, but not really
>  > trivial, and I'm a little busy. If someone wants to help....
>
> I was thinking a few days ago. With your move of all this stuff to
> userspace, if it was done in multiple stages, we could implement
> a form of checkpointing this way.
>
> So instead of doing the 'suspend to disk/ram' after 'write out all pages',
> we just continue.
>
> Why is this useful ?  We've seen bugs reported that only ever bite
> customers after they've run their workload for a month.  Now, if they had a
> means of checkpointing, then when it crashes, they could capture the last
> image that landed somewhere, and set that up for more tests/monitoring with
> kprobes etc and reproduce those hard-to-reproduce bugs a lot faster.

I've been asked about this from time to time too. Apart from the issues Pavel 
has already mentioned, the big problem in my mind was figuring out what to do 
about disk storage. As the algorithm stands at the moment, the image includes 
information about the state of mounted filesystems. We'd need to somehow get 
rid of or be able to ignore that. Any suggestions?

Regards,

Nigel
-- 
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net                IRC: #suspend2 on Freenode

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]