Re: [ 00/10] [Suspend2] Modules support.

[Olivier Galibert <galibert@pobox.com>]

On Fri, Feb 03, 2006 at 06:24:44PM +0100, Rafael J. Wysocki wrote:
> I use it on a daily basis.  It works.

The plural of anecdote is not data.  Nobody except Pavel and you ever
wrote code to work in the userland part of your suspend.  But the aim
is to have GUI-type code written by other people running between the
snapshotting and the system shutdown, right?  Code that is pretty much
by definition just plain untrustable in the first place.

The interactions with a frozen, direct-rendering X are going to be
quite amusing too.  You'll have to be very careful to switch VTs to a
suspend-aware framebuffer before snapshotting.  That could help
reducing your video-card related problems though.


> The suspending helper should not use mounted filesystems after it
> calls the atomic snapshot ioctl().

You can s/mounted// on that.  It's pretty much impossible to unmount
filesystems on a running system, it's always kept busy by something.
Especially system filesystems.


> The resuming helper should be run from
> an initrd and all filesystems should be unmounted at that time (of course
> it should not attempt to mount them).

Mandatory initrd?  How nice...


> > Will the fs be in a coherent state after resume?
> 
> Yes, it will, as long as the helpers follow some strict rules (above).

That's exactly what I'm terribly afraid of.  You have no way to
enforce them, so they won't be respected.  And filesystems will die
randomly and unpredictably.


> > The idea of trying to save a state that can be modified dynamically
> > while you're saving in unpredictable ways makes me very, very afraid.
> > At least when you're in the kernel you can have complete control over
> > the machine when needed.
> 
> Not necessarily.  For example, if you suspend the box and then start it with
> a wrong kernel that is unable to read the image, it will mount the file
> systems and you loose the saved state.

You can always limit the damage by syncing the disks before
snapshotting.  This way you'll only lose the running processes if you
don't actually resume.  While having the in-memory cache of the state
of the filesystem being different of the real on-disk state eats
filesystems for breakfast.  The output of fsck is not pretty.
BTDTGTTS.

  OG.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/