> On 1998-06-12T11:12:24,
> Larry McVoy <lm@bitmover.com> said:
>
> > : a process, you have to snapshot all related processes and the state of
> > : the kernel. It's a much better idea to have general persistency and take
> > : periodic system-wide snapshots.
> >
> > Yup. But throw a cluster into the mix and think about saving the state
> > of all those sockets. It's doable, just a pain in the butt.
>
> I am dreaming of doing an "atomic" cp /proc/pid/<> newhost:/proc/ *g*
>
> Seriously: Shouldn't be all information relating to a process and it's
> resource reside in /proc? This might be the first step to get process
> migration going, since then you could implement a clean interface.
>
> (You can implement this using other tricks, but using the proc fs has a
> certain "clean" and consistent appeal to me)
It seems a lot of people hasn't understood that moving a process is
*far* more than just it's resources. It's less the silver bullet that
many people dream of than more the dragon hiding between the cluster's
back.
Think of issues like a filepointer for a file which has grown since the
process snapshot was taken / started to be moved. Assume it was pointing
to the last byte and the file has grown. So now, where to position the
file when relaunching the process?
If we want to implement checkpoint/restore for the common case, then
in my opinion the only useable way of doing this is to make applications
that know how to create/restore snapshots of themselves. Which again
produces interesting security issues - which luckily aren't of interest
for most apps but still want to be solved.
Ralf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu