process checkpoint restore facility now in DragonFly BSD

Kip Macy kmacy at netapp.com
Wed Jan 12 13:30:45 PST 2005


I've promised Nate to port the functionality to FreeBSD. I'm busy doing some 
things with the FreeBSD port to Xen at the moment. 

Checkpointing a process is intrinsically messy for reasons beyond the obvious
statefulness of TCP connections. Process state, particularly with regard to
devices, is often not cleanly associated with the process in the kernel. What
happens if a file that the process had open has gone away? Other issues abound - 
checkpointing a process pipeline can be made to work, but some work would need 
to be done on pipes. The list goes on.


					-Kip


On Wed, 12 Jan 2005, Siddharth Aggarwal wrote:

> 
> Hi all,
> 
> I am responding to a post back in Oct 2003 when the checkpointing feature
> was announced for DragonFly. I have been doing some research on this, and
> have seen some projects that use Xen VMM to achieve checkpoints of guest
> OSes.
> 
> So I was looking for inputs from people as to what everyone feels about
> checkpointing, whether it should be done at the physical machine level or
> VM level. Pros and Cons of each approach, if any further development was
> done on DragonFly for checkpoint since then and if it was stopped, why?
> Are there serious limitations to checkpointing a physical machine?
> 
> Sorry for such a vague posting, but I thought this would be a good
> platform to get some feedback.
> 
> Thanks,
> Sid.
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
> 

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan


More information about the freebsd-hackers mailing list