From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 12 21:40:42 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B51F16A4CE for ; Wed, 12 Jan 2005 21:40:42 +0000 (GMT) Received: from mail-svr1.cs.utah.edu (brahma.cs.utah.edu [155.98.64.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9A6243D2D for ; Wed, 12 Jan 2005 21:40:41 +0000 (GMT) (envelope-from saggarwa@cs.utah.edu) Received: from localhost (localhost [127.0.0.1]) by mail-svr1.cs.utah.edu (Postfix) with ESMTP id E25EC346EE; Wed, 12 Jan 2005 14:40:39 -0700 (MST) Received: from mail-svr1.cs.utah.edu ([127.0.0.1]) by localhost (mail-svr1.cs.utah.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26735-06; Wed, 12 Jan 2005 14:40:39 -0700 (MST) Received: from faith.cs.utah.edu (faith.cs.utah.edu [155.98.65.40]) by mail-svr1.cs.utah.edu (Postfix) with ESMTP id 707C9346E0; Wed, 12 Jan 2005 14:40:39 -0700 (MST) Received: by faith.cs.utah.edu (Postfix, from userid 4973) id 546072EC21; Wed, 12 Jan 2005 14:40:39 -0700 (MST) Received: from localhost (localhost [127.0.0.1]) by faith.cs.utah.edu (Postfix) with ESMTP id 1EE8B34406; Wed, 12 Jan 2005 21:40:39 +0000 (UTC) Date: Wed, 12 Jan 2005 14:40:39 -0700 (MST) From: Siddharth Aggarwal To: Kip Macy In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: amavisd-new at cs.utah.edu cc: freebsd-hackers@freebsd.org Subject: Re: process checkpoint restore facility now in DragonFly BSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 21:40:42 -0000 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" >