Re: Re: standby to disk transition

["Rafael J. Wysocki" <rjw@sisk.pl>]

[-- Attachment #1: Type: text/plain, Size: 1758 bytes --]

On Monday 13 March 2006 23:08, Pavel Machek wrote:
> > >  > 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?
> 
> Well, copying all the filesystems would work, as would having no
> filesystems at all :-) [ramdisk case]. And perhaps practical
> equivalent of "copy all filesystems" can be done with device mapper.
> 
> [Of course, you'd have to copy all the filesystems back before doing
> resume].

If we had anything like fs suspend/resume, we could handle such things.
We could also handle the "USB device mounted before suspend" problem
(I think it's related).

Greetings,
Rafael

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