Re: RFC: Self-snapshotting in Linux

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?
begin:vcard
fn:Scott Lovenberg
n:Lovenberg;Scott
org:The CleftStone Works
adr:;;;Kutztown;PA;19530;USA
email;internet:scott.lovenberg@xxxxxxxxx
tel;cell:570-856-2999
note;quoted-printable:Interests:=0D=0A=
	Programming, *NIX, Slackware, Samba, C/C++, Perl, Java, .NET, Kernel Hack=
	ing, Virtual Machines, FOSS, Security, Operating Systems, Various Softwar=
	e Stacks.  =
	=0D=0A=
	=0D=0A=
	Always have time for "shop talk"; feel free to drop me a line.
x-mozilla-html:TRUE
url:www.cleftstoneworks.com
version:2.1
end:vcard


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux