From: "Peter Teoh" <htmldeveloper@gmail.com>
To: "Alan Jenkins" <alan-jenkins@tuffmail.co.uk>
Cc: "Scott Lovenberg" <scott.lovenberg@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: RFC: Self-snapshotting in Linux
Date: Wed, 16 Apr 2008 23:06:05 +0800 [thread overview]
Message-ID: <804dabb00804160806o39a2c89eg8d3a3387beb7b5cb@mail.gmail.com> (raw)
In-Reply-To: <db1091b2-68a6-4f71-800e-c4df6f8641ca@m44g2000hsc.googlegroups.com>
On 4/16/08, Alan Jenkins <alan-jenkins@tuffmail.co.uk> wrote:
> Scott Lovenberg wrote:
>
> > Peter Teoh wrote:
> > Maybe you load up another kernel to handle the snapshot, and then hand
> > the system back to it afterwards? What do you think?
>
>
> Isn't that just what Ying Huans kexec-based hibernation does?
>
This list is awesome. After I read up on this kexec-based hibernation thing:
http://kerneltrap.org/node/11756
I realized it is about the same idea. Some differences though:
My original starting point was VMWare's snapshot idea. Drawing an
analogy from there, the idea is to freeze and restore back entire
kernel + userspace application. For integrity reason, filesystem
should be included in the frozen image as well.
Currently, what we are doing now is to have a bank of Norton
Ghost-based images of the entire OS and just selectively restoring
back the OS we want to work on. Very fast - less than 30secs the
entire OS can be restored back. But problem is that it need to be
boot up - which is very slow. And there userspace state cannot be
frozen and restored back.
VMWare images is slow, and cannot meet bare-metal CPU/direct hardware
access requirements. There goes Xen's virtualization approach as
well.
Another approach is this (from an email by Scott Lovenberg) - using
RELOCATABLE kernel (or may be not?????I really don't know, but idea is
below):
a. Assuming we have 32G (64bit hardware can do that) of memory, but
we want to have 7 32-bit OS running (not concurrently) - so then
memory is partition into 8 x 4GB each - the lowest 4GB reserved for
the current running OS. Each OS will be housed into each 4G of
memory. When each OS is running, it will access its own partition on
the harddisk/memory, security concerns put aside. Switching from one
OS to another OS is VOLUNTARILY done by the user - equivalent to that
of "desktop" feature in Solaris CDE. Restoring back essentially is
just copying from each of the 4GB into the lowest 4GB memory range.
Because only the lowest 4gb is used, only 32 bit instruction is
needed, 64bit is needed only when copying from one 4GB memory
partition into the lowest 4GB region, and vice versa. And together
with using partitioning of harddisk for each OS, switching among the
different OS kernel should be in seconds, much less than 1 minute,
correct?
Technically, does the above sound feasible?
--
Regards,
Peter Teoh
next prev parent reply other threads:[~2008-04-16 15:06 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <ajbvb-3Ur-21@gated-at.bofh.it>
[not found] ` <ajcri-65w-13@gated-at.bofh.it>
2008-04-16 10:27 ` Alan Jenkins
2008-04-16 11:12 ` Pavel Machek
2008-04-16 13:50 ` Alan Jenkins
2008-04-17 9:32 ` Pavel Machek
2008-04-19 16:42 ` Alan Jenkins
2008-04-17 0:55 ` Nigel Cunningham
2008-04-17 7:48 ` Alan Jenkins
[not found] ` <ajd42-7Gt-49@gated-at.bofh.it>
2008-04-16 11:02 ` Alan Jenkins
2008-04-16 15:06 ` Peter Teoh [this message]
2008-04-16 16:21 ` Disconnect
2008-04-16 19:50 ` Vivek Goyal
[not found] ` <48065C64.7010808@gmail.com>
2008-04-16 20:10 ` Scott Lovenberg
2008-04-16 20:25 ` Vivek Goyal
2008-04-17 2:09 ` Scott Lovenberg
2008-04-17 6:23 ` Peter Teoh
2008-04-17 8:43 ` Alan Jenkins
2008-04-17 16:01 ` Scott Lovenberg
2008-04-16 8:44 Peter Teoh
2008-04-16 8:49 ` eric miao
2008-04-16 9:49 ` Ben Nizette
2008-04-16 10:33 ` Scott Lovenberg
2008-04-16 11:14 ` Pavel Machek
[not found] ` <804dabb00804160821n4872c65fh44f2c07ead67fc49@mail.gmail.com>
2008-04-17 9:33 ` Pavel Machek
2008-04-16 18:31 ` Greg Freemyer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=804dabb00804160806o39a2c89eg8d3a3387beb7b5cb@mail.gmail.com \
--to=htmldeveloper@gmail.com \
--cc=alan-jenkins@tuffmail.co.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=scott.lovenberg@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®