Re: [C/R v20][PATCH 38/96] c/r: dump open file descriptors

[xing lin <linxingnku-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

Hi, I am Xing, a PHD candidate in University of Utah. I am also quite
interested in container-based virtualization.  That's why I register this
email list. :)

Now, I am working on Container migration of OpenVZ in Emulab. I just begin
to hack OpenVZ kernel.

On Sun, Mar 21, 2010 at 3:36 PM, Oren Laadan <orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org> wrote:

>
> Let's separate the issues of file system snapshot and deleted files.
>
> 1) File system snapshot:
> ------------------------
> The requirement is to preserve the file system state between the time
> of the checkpoint and the time of the restart, because userspace will
> expect it to remain the same.
>
> The alternatives are:
>
> a) Use capable file system, like brfs, or (modified) nilfs.
>

Do you mean btrfs? These two file systems both support snapshot. Sound
great.

b) Userspace saves the state e.g. w/ tar or rsync (maybe incremental)
>
> c) Assume/expect that the file system isn't modified between checkpoint
> and restart (e.g. if we use c/r to suspend a user's session)
>

This is what OpenVZ does. OpenVZ assumes the underlying file system to be
consistent during checkpoint and restart. If the file does not exist when
restoring the container, the restoring will fail(It will give a message to
show which file can not be found). OpenVZ also does not support nfs. If a
nfs is mounted in the container's file system, this container can not be
suspended. Since we want to enable container migration in Emulab, so we are
trying to solve these issues. nfs is the big issue since almost all users
will store their files at their home directories which are mounted from the
nfs server. We are still discussing how to deal with this.

-- 
Regards,
Xing
School of Computing, University of Utah
http://www.cs.utah.edu/~xinglin/