Hibernation maybe ... try "echo "disk" > /sys/power/state"

On Wed, Apr 16, 2008 at 4:44 PM, Peter Teoh wrote:
> Sorry if this is a a crazy idea.....just be forewarned....
>
> First, I would like to make a reference to VMWare's snapshot (name not
> important, emphasize the idea) feature - hopefully u are familiar with
> it. This is a feature whereby u can freeze the entire OS (kernel +
> userspace application running) and then later reload itself next time,
> continuing where it left off, without reboot from ground zero.
>
> Next, can I ask, is such a feature useful in Linux? Ie, able to
> restart the kernel + userspace application from where u left off, the
> last time round. Not JUST the normal suspend/resume feature, but
> more important able to CHOOSE among the different available images for
> u to resume on. Eg, u want to freeze the current 2.6.25-rc6 kernel,
> save it, and then restore back the 2.6.23-rc5 image, work on it, save
> it, and then restore the previous image again. All done without
> virtualization as in the VMWare sense - which really is CPU intensive
> and slow things down a lot. Now we can directly execute each OS
> kernel image on the CPU, and since saving and restoring is quite fast
> (eg, zipping up the entire physical memory before saving into
> permanent storage) - I supposed this will be much faster than the
> normal initialization/fsck work done normally....or did I missed out
> anything?
>
> Essentially, to reiterate the key idea: able to snapshot the current
> kernel+userspace permanent.....restore from another snapshot....and
> then switch back again if needed etc.....will the implementation be
> difficult...if not impossible????
>
> --
> Regards,
> Peter Teoh
> --
> 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/
>



--
Cheers
- eric
--
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/

On Wed, 2008-04-16 at 16:44 +0800, Peter Teoh wrote:
> Essentially, to reiterate the key idea: able to snapshot the current
> kernel+userspace permanent.....restore from another snapshot....and
> then switch back again if needed etc.....will the implementation be
> difficult...if not impossible????
>

As I see it the main thing is that VMWare doesn't have to worry about
trying to put hardware in to (and pull out of) low power modes. VMWare
hardware is never left in an undefined state by poorly written drivers
etc.

I think hibernation is about what you want; snapshotting as you describe
it should fall down for about the same reasons :-)

--Ben.
--
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/

Peter Teoh wrote:
> Sorry if this is a a crazy idea.....just be forewarned....
>
> First, I would like to make a reference to VMWare's snapshot (name not
> important, emphasize the idea) feature - hopefully u are familiar with
> it. This is a feature whereby u can freeze the entire OS (kernel +
> userspace application running) and then later reload itself next time,
> continuing where it left off, without reboot from ground zero.
>
> Next, can I ask, is such a feature useful in Linux? Ie, able to
> restart the kernel + userspace application from where u left off, the
> last time round. Not JUST the normal suspend/resume feature, but
> more important able to CHOOSE among the different available images for
> u to resume on. Eg, u want to freeze the current 2.6.25-rc6 kernel,
> save it, and then restore back the 2.6.23-rc5 image, work on it, save
> it, and then restore the previous image again. All done without
> virtualization as in the VMWare sense - which really is CPU intensive
> and slow things down a lot. Now we can directly execute each OS
> kernel image on the CPU, and since saving and restoring is quite fast
> (eg, zipping up the entire physical memory before saving into
> permanent storage) - I supposed this will be much faster than the
> normal initialization/fsck work done normally....or did I missed out
> anything?
>
> Essentially, to reiterate the key idea: able to snapshot the current
> kernel+userspace permanent.....restore from another snapshot....and
> then switch back again if needed etc.....will the implementation be
> difficult...if not impossible????
>
>
Hrm... well, the kernel has the ability since 2.6.20 (although its in
testing AFAIK) to relocate itself on a crash. Reference:


Relocatable kernel support for x86

This feature (enabled with CONFIG_RELOCATABLE) isn't very noticeable for
end-users but it's quite interesting from a kernel POV. Until now, it
was a requirement that a i386 kernel was loaded at a fixed memory
address in order to work, loading it in a different place wouldn't work.
This feature allows to compile a kernel that can be loaded at different
4K-aligned addresses, but always below 1 GB, with no runtime overhead.
Kdump users (a feature introduced in 2.6.13
that triggers kexec
in a kernel crash in order to boot a
kernel that has been previously loaded at an 'empty' address, then runs
that kernel, saves the memory where the crashed kernel was placed, dumps
it in a file and continues booting the system) will benefit from this
because until now the "rescue kernel" needed to be compiled with
different configuration options in order to make it bootable at a
different address. With a relocatable kernel, the same kernel can be
booted at different addresses. (commit 1
,
2
,
3
,
4)




Maybe you load up another kernel to handle the snapshot, and then hand
the system back to it afterwards? What do you think?

> Sorry if this is a a crazy idea.....just be forewarned....
>
> First, I would like to make a reference to VMWare's snapshot (name not
> important, emphasize the idea) feature - hopefully u are familiar with
> it. This is a feature whereby u can freeze the entire OS (kernel +
> userspace application running) and then later reload itself next time,
> continuing where it left off, without reboot from ground zero.
>
> Next, can I ask, is such a feature useful in Linux? Ie, able to
> restart the kernel + userspace application from where u left off, the
> last time round. Not JUST the normal suspend/resume feature, but
> more important able to CHOOSE among the different available images
> for
> u to resume on. Eg, u want to freeze the current 2.6.25-rc6
> kernel,

Could we use english on this list?

Anyway, hibernate, cp /dev/root /somewhere/root.1; cp /dev/swap
/somewhere/swap.1

If you want to resume selected version, copy back that set of devices,
and proceed normally.

Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pav...rses/blog.html
--
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/

On Wed, Apr 16, 2008 at 4:44 AM, Peter Teoh wrote:
> Sorry if this is a a crazy idea.....just be forewarned....
>
> First, I would like to make a reference to VMWare's snapshot (name not
> important, emphasize the idea) feature - hopefully u are familiar with
> it. This is a feature whereby u can freeze the entire OS (kernel +
> userspace application running) and then later reload itself next time,
> continuing where it left off, without reboot from ground zero.
>
> Next, can I ask, is such a feature useful in Linux? Ie, able to
> restart the kernel + userspace application from where u left off, the
> last time round. Not JUST the normal suspend/resume feature, but
> more important able to CHOOSE among the different available images for
> u to resume on. Eg, u want to freeze the current 2.6.25-rc6 kernel,
> save it, and then restore back the 2.6.23-rc5 image, work on it, save
> it, and then restore the previous image again. All done without
> virtualization as in the VMWare sense - which really is CPU intensive
> and slow things down a lot. Now we can directly execute each OS
> kernel image on the CPU, and since saving and restoring is quite fast
> (eg, zipping up the entire physical memory before saving into
> permanent storage) - I supposed this will be much faster than the
> normal initialization/fsck work done normally....or did I missed out
> anything?
>
> Essentially, to reiterate the key idea: able to snapshot the current
> kernel+userspace permanent.....restore from another snapshot....and
> then switch back again if needed etc.....will the implementation be
> difficult...if not impossible????
>
> --
> Regards,
> Peter Teoh

By using LVM-2 snapshots you can already do this with data drives.

So if you setup a XEN setup where the DomU boot drives are Dom0 LVs
you should be golden.

Ie. from Dom0 you can create/restore your snapshots of your DomU instances.

It may also be possible to make LVM snapshots work with the root
partition of the physical boot drive, but that would take initrd magic
I have never tried.

Greg
--
Greg Freemyer
Litigation Triage Solutions Specialist
http://www.linkedin.com/in/gregfreemyer
First 99 Days Litigation White Paper -
http://www.norcrossgroup.com/forms/w...whitepaper.pdf

The Norcross Group
The Intersection of Evidence & Technology
http://www.norcrossgroup.com
--
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/

On Wed 2008-04-16 23:21:05, Peter Teoh wrote:
> Thank you for your reply.
>
> Just some questions...
>
> On 4/16/08, Pavel Machek wrote:
> > > Sorry if this is a a crazy idea.....just be forewarned....
> > >
> > > First, I would like to make a reference to VMWare's snapshot (name not
> > > important, emphasize the idea) feature - hopefully u are familiar with
> > > it. This is a feature whereby u can freeze the entire OS (kernel +
> > > userspace application running) and then later reload itself next time,
> > > continuing where it left off, without reboot from ground zero.
> > >
> > > Next, can I ask, is such a feature useful in Linux? Ie, able to
> > > restart the kernel + userspace application from where u left off, the
> > > last time round. Not JUST the normal suspend/resume feature, but
> > > more important able to CHOOSE among the different available images
> > > for
> > > u to resume on. Eg, u want to freeze the current 2.6.25-rc6
> > > kernel,
> >
> >
> > Could we use english on this list?
> >
> > Anyway, hibernate, cp /dev/root /somewhere/root.1; cp /dev/swap
> > /somewhere/swap.1
> >
>
> The current userspace suspend actually saved the entire state of the
> memory (which applications are oepne/closed) into the swap area,
> right?

> So the 2nd line above of backingup the swap should allow us to restore
> back state of the userspace applications later - correct?

Yes, but you need to match memory state with filesystem state...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pav...rses/blog.html
--
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/