lkml.org 
[lkml]   [2009]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC v13][PATCH 00/14] Kernel based checkpoint/restart
From
Date
On Thu, 2009-02-12 at 10:11 -0800, Dave Hansen wrote:

> > - In bullet-point form, what features are missing, and should be added?
>
> * support for more architectures than i386
> * file descriptors:
> * sockets (network, AF_UNIX, etc...)
> * devices files
> * shmfs, hugetlbfs
> * epoll
> * unlinked files

> * Filesystem state
> * contents of files
> * mount tree for individual processes
> * flock
> * threads and sessions
> * CPU and NUMA affinity
> * sys_remap_file_pages()

I think the real questions is: where are the dragons hiding? Some of
these are known to be hard. And some of them are critical checkpointing
typical applications. If you have plans or theories for implementing all
of the above, then great. But this list doesn't really give any sense of
whether we should be scared of what lurks behind those doors.

Some of these things we probably don't have to care too much about. For
instance, contents of files - these can legitimately change for a
running process. Open TCP/IP sockets can legitimately get reset as well.
But others are a bigger deal.

Also, what happens if I checkpoint a process in 2.6.30 and restore it in
2.6.31 which has an expanded idea of what should be restored? Do your
file formats handle this sort of forward compatibility or am I
restricted to one kernel?

--
http://selenic.com : development and support for Mercurial and Linux




\
 
 \ /
  Last update: 2009-02-12 20:33    [W:0.199 / U:0.920 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site