Date: Wed, 12 Jan 2005 13:45:58 -0800 (PST) From: Kip Macy <kmacy@netapp.com> To: Siddharth Aggarwal <saggarwa@cs.utah.edu> Cc: freebsd-hackers@freebsd.org Subject: Re: process checkpoint restore facility now in DragonFly BSD Message-ID: <Pine.LNX.4.44.0501121343050.13750-100000@siml3.eng.netapp.com> In-Reply-To: <Pine.GSO.4.50L0.0501121439560.4512-100000@faith.cs.utah.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Taking this off list. -Kip On Wed, 12 Jan 2005, Siddharth Aggarwal wrote: > > Thanks for your reply. > > I understand the complexity of checkpointing a process and I do agree that > capturing the complete state of a system is really difficult. So my > question is that if a subset of that functinality was to be implemented > (e.g. not guaranteeing certain things to processes when they restart, and > I believe that you have already implemented this for DragonFly), why is it > more difficult to do it for a physical machine versus in a VMM like Xen? > Or do you have any arguments in the reverse direction i.e. > better/easier/efficient/reliable in a physical machine than a VMM? Or do > you now believe since this feature was implemented over a year ago, that a > VMM is the way to go? > > > > On Wed, 12 Jan 2005, Kip Macy wrote: > > > 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@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@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 > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.44.0501121343050.13750-100000>