From: "Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
To: Oren Laadan <orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
Cc: containers <containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org>,
Dave Hansen
<dave-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Subject: Re: [BIG RFC] Filesystem-based checkpoint
Date: Thu, 30 Oct 2008 15:03:34 -0500 [thread overview]
Message-ID: <20081030200334.GA20459@us.ibm.com> (raw)
In-Reply-To: <490A0F67.5000303-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
Quoting Oren Laadan (orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org):
>
>
> Serge E. Hallyn wrote:
> > Quoting Oren Laadan (orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org):
> > What Dave is suggesting (as I understand it) is just changing the way
> > the data is shipped between kernel and user-space. But to continue with
> > sys_checkpoint() and sys_restart(). So I think it's a less fundamental
> > change than you are thinking.
>
> Probably true, if you ignore the tree he used to illustrate the idea :o
> If we agree on the 'blob' (or nearly 'blob') approach, he should suggest
> to export a single file (or one file per task, but that's _it_).
Well no. I'm saying that the problem with cryo was that you had to use
tons of different APIs - and introduce a few new ones - to grab info
about various resources using their own API. Yes Dave looks to be
making you grab all the info in fine-grained pieces through individual
files, but each bit of info is consumed using the exact same API.
> Can you comment on point 3, that is --
>
> 3. Your approach doesn't play well with what I call "checkpoint that
> involves self". This term refers to a process that checkpoints itself
> (and only itself), or to a process that attempts to checkpoint its own
> container. In both cases, there is no other entity that will read the
> data from the file system while the caller is blocked.
This is where I seem to recall Dave mentioning some crazy scheme where
the task would clone itself and have its clone do the pulling.
Don't get me wrong - I'm not sure what Dave's intentions are, but I
agree with you that we should keep working on pushing your patchset.
If we get a nack based on the set_fs() stuff then we know to go with
Dave's approach (or some other), otherwise Dave can keep pursuing his
idea in his sandbox. But I do think his idea is cool. Not all cool
ideas end up being workable, so we'll see...
/me now goes to try lxc-checkpoint with Oren's patches.
-serge
next prev parent reply other threads:[~2008-10-30 20:03 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-28 18:37 [BIG RFC] Filesystem-based checkpoint Dave Hansen
2008-10-28 20:56 ` Serge E. Hallyn
[not found] ` <20081028205654.GA17487-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2008-10-28 21:00 ` Dave Hansen
2008-10-28 21:10 ` Dave Hansen
2008-10-30 16:25 ` Oren Laadan
[not found] ` <4909E000.9070201-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2008-10-30 16:36 ` Dave Hansen
2008-10-30 18:19 ` Oren Laadan
[not found] ` <4909FAA8.5000107-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2008-10-30 19:28 ` Serge E. Hallyn
[not found] ` <20081030192817.GA16340-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2008-10-30 19:39 ` Dave Hansen
2008-10-30 19:50 ` Serge E. Hallyn
2008-10-30 19:47 ` Oren Laadan
[not found] ` <490A0F67.5000303-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2008-10-30 20:03 ` Serge E. Hallyn [this message]
2008-10-30 20:11 ` Dave Hansen
2008-11-04 21:33 ` Mike Waychison
2008-10-30 19:37 ` Dave Hansen
2008-10-30 20:15 ` Oren Laadan
[not found] ` <490A15F5.6010702-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2008-10-30 20:40 ` Dave Hansen
2008-10-30 23:33 ` Eric W. Biederman
[not found] ` <m163n9y7yb.fsf-B27657KtZYmhTnVgQlOflh2eb7JE58TQ@public.gmane.org>
2008-10-31 0:09 ` Dave Hansen
2008-10-31 3:12 ` Eric W. Biederman
[not found] ` <m1k5bpwj8j.fsf-B27657KtZYmhTnVgQlOflh2eb7JE58TQ@public.gmane.org>
2008-10-31 10:22 ` Louis Rilling
2008-10-31 13:48 ` Serge E. Hallyn
2008-10-31 14:21 ` Dave Hansen
2008-10-31 20:51 ` Eric W. Biederman
[not found] ` <m1r65wpjx2.fsf-B27657KtZYmhTnVgQlOflh2eb7JE58TQ@public.gmane.org>
2008-11-03 17:23 ` Dave Hansen
2008-11-03 17:48 ` Dave Hansen
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=20081030200334.GA20459@us.ibm.com \
--to=serue-r/jw6+rmf7hqt0dzr+alfa@public.gmane.org \
--cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
--cc=dave-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
--cc=orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.