Hi.

On Thu, 2007-04-26 at 09:56 -0700, Linus Torvalds wrote:
quoted text
>=20
> On Thu, 26 Apr 2007, Nigel Cunningham wrote:
> >=20
> > * Doing things in the right order? (Prepare the image, then do the
> > atomic copy, then save).
>=20
> I'd actually like to discuss this a bit..
>=20
> I'm obviously not a huge fan of the whole user/kernel level split and=20
> interfaces, but I actually do think that there is *one* split that makes=20
> sense:
>=20
>  - generate the (whole) snapshot image entirely inside the kernel
>=20
>  - do nothing else (ie no IO at all), and just export it as a single imag=
e=20
quoted text
>    to user space (literally just mapping the pages into user space).=20
>    *one* interface. None of the "pretty UI update" crap. Just a single=20
>    system call:
>=20
> 	void *snapshot_system(u32 *size);
>=20
>    which will map in the snapshot, return the mapped address and the size=
=20
quoted text
>    (and if you want to support snapshots > 4GB, be my guest, but I suspec=
t=20
quoted text
>    you're actually *better* off just admitting that if you cannot shrink=20
>    the snapshot to less than 32 bits, it's not worth doing)

That inherently limits the image to half of available ram (you need
somewhere to store the snapshot), so you won't get the full image you
express interest in below.

quoted text
> User space gets a fully running system, with that one process having that=
=20
quoted text
> one image mapped into its address space. It can then compress/write/do=20
> whatever to that snapshot.

You're describing uswsusp! (At least in so far as I understand it!).

You can't get a fully running system though, because if anything changes
something on disk that was snapshotted (super blocks etc) your snapshot
is invalid and you risk on-disk corruption.

quoted text
> And btw, the device model changes are a big part of this. Because I don't=
=20
quoted text
> think it's even remotely debuggable with the full suspend/resume of the=20
> devices being part of generating the image! That freeze/snapshot/unfreeze=
=20
quoted text
> sequence is likely a lot more debuggable, if only because freeze/unfreeze=
=20
quoted text
> is actually a no-op for most devices, and snapshotting is trivial too.
>=20
> Once you have that snapshot image in user space you can do anything you=20
> want. And again: you'd hav a fully working system: not any degradation=20
> *at*all*. If you're in X, then X will continue running etc even after the=
=20
quoted text
> snapshotting, although obviously the snapshotting will have tried to page=
=20
quoted text
> a lot of stuff out in order to make the snapshot smaller, so you'll likel=
y=20
quoted text
> be crawling.

Nooooooo! See above about disk corruption.

quoted text
> > * Mulithreaded I/O (might as well use multiple cores to compress the
> > image, now that we're hotplugging later).
> > * Support for > 1 swap device.
> > * Support for ordinary files.
> > * Full image option.
> > * Modular design?
>=20
> I'd really suggest _just_ the "full image". Nothing else is probably ever=
=20
quoted text
> worth supporting. Your "snapshot to disk" wouldn't be _quite_ as simple a=
s=20
quoted text
> "echo disk > /sys/power/state", but it should not necessarily be much=20
> worse than

Please, go apply that logic elsewhere, then cut out (or at least stop
adding) support for users with less common needs in other areas. I fully
acknowledge that most users have only one place to store their image and
it's a swap device. But that doesn't mean one size fits all.

A full image implies that you need to figure out what's not going to
change while you're writing it and save that separately. At the moment,
I'm treating most of the LRU contents as that list. If we're going to
start trying to let every man and his dog run while we're trying to
snapshot the system, that's not going to work anymore - or the logic
will get a lot more complicated.

Sorry. I never thought I'd say this, but I think you're being naive
about how simple the process of snapshotting a system is.

Regards,

Nigel