Re: Back to the future.

[Nigel Cunningham <nigel@nigel.suspend2.net>]

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

Hi.

On Fri, 2007-04-27 at 14:44 -0700, Linus Torvalds wrote:
> 
> On Fri, 27 Apr 2007, Rafael J. Wysocki wrote:
> > 
> > Why do you think that keeping the user space frozen after 'snapshot' is a bad
> > idea?  I think that solves many of the problems you're discussing.
> 
> It makes it harder to debug (wouldn't it be *nice* to just ssh in, and do
> 
> 	gdb -p <snapshotter>

Make the machine being suspended a VM and you can already do that.

> when something goes wrong?) but we also *depend* on user space for various 
> things (the same way we depend on kernel threads, and why it has been such 
> a total disaster to try to freeze the kernel threads too!). For example, 
> if you want to do graphical stuff, just using X would be quite nice, 
> wouldn't it?

It would be nice, yes.

But in doing so you make the contents of the disk inconsistent with the
state you've just snapshotted, leading to filesystem corruption. Even if
you modify filesystems to do checkpointing (which is what we're really
talking about), you still also have the problem that your snapshot has
to be stored somewhere before you write it to disk, so you also have to
either

1) write some known static memory to disk before the snapshot and reuse
it for the snapshot,
2) ensure up to half the RAM is free for your snapshot or 
3) compress the snapshot as you take it, guessing beforehand how much
memory the compressed snapshot might take and freeing that might
4) reserve memory at boot time for the atomic copy so that 2) or 3) is
still done, but without having to free the memory. (Yuk!).

> But I do agree that doing everythign in the kernel is likely to just be a 
> hell of a lot simpler for everybody.

Indeed.

Nigel

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]