[Devel] Re: [PATCH 00/30] C/R OpenVZ/Virtuozzo style
Oren Laadan
orenl at cs.columbia.edu
Mon Apr 13 22:46:36 PDT 2009
Some meta comments about this patch set:
* Patches 1-9 are cleanups, unrelated to checkpoint/restart. They
deserve a separate thread.
* You barely take locks or reference counts to objects that you
later refer to. What if something really bad happens ?
* (contd) If you don't take locks, then you at the very least need
to rely on the container remaining frozen for the duration of the
operation (during checkpoint).
* (contd) Still with locks and references, during restart you can't
even freeze the container, so need extra logic to prevent bad things
(e.g. OOM killer, signal or ptrace from parent container etc).
* What is the rationale behind doing the freeze/unfreeze from within
sys_checkpoint/sys_restart ? Instead of you let userspace do it
(and only verify in kernel) you gain, again, flexibility. For example,
you want to also snapshot the filesystem, then userspace will do
something like: freeze container -> snapshot filesystem -> checkpoint
-> thaw container.
* A plethora of "FIXME" comments ...
Alexey Dobriyan wrote:
> This is to show how we see C/R and to provoke discussion on number of
> important issues (mounts, ...).
Quoting your patch:
---
This is one big FIXME:
What to do with overmounted files?
What to do with mounts at all, who should restore them?
just restore something to not oops on task exit
---
>
> This is small part of long-awaited to be cleanuped code.
>
> It's able to restore busyloop on i386 and x86_64 and restore i386
> busyloop on x86_64. It wasn't tested much more than that.
Oh .. I really wish you'd sent a x86_64 patch our way, too ;)
>
> I'm currently starting formal testsuite, otherwise it's whack-a-mole
> game and formal TODO list (a huge one).
>
So I'm still struggling to see the major different in the approaches
that would justify throwing away our hard worked, reviewed, tested
and functional code, and take this - similar in design, largely
incomplete and unreviewed code.
Best,
Oren.
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
More information about the Devel
mailing list