From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756427AbXGIPga (ORCPT ); Mon, 9 Jul 2007 11:36:30 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753724AbXGIPgX (ORCPT ); Mon, 9 Jul 2007 11:36:23 -0400 Received: from rwcrmhc11.comcast.net ([216.148.227.151]:38996 "EHLO rwcrmhc11.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752710AbXGIPgW (ORCPT ); Mon, 9 Jul 2007 11:36:22 -0400 From: Jeremy Maitin-Shepard To: Alan Stern Cc: Pavel Machek , "Rafael J. Wysocki" , pm list , LKML , Nigel Cunningham , Oliver Neukum , Miklos Szeredi , Benjamin Herrenschmidt , Matthew Garrett , Ingo Molnar Subject: Re: [RFC][PATCH -mm] Freezer: Handle uninterruptible tasks References: X-Habeas-SWE-9: mark in spam to . X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-1: winter into spring Date: Mon, 09 Jul 2007 11:36:13 -0400 In-Reply-To: (Alan Stern's message of "Mon\, 9 Jul 2007 10\:45\:56 -0400 \(EDT\)") Message-ID: <87tzsdvbbm.fsf@jbms.ath.cx> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.990 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Alan Stern writes: > On Mon, 9 Jul 2007, Jeremy Maitin-Shepard wrote: >> Pavel Machek writes: >> >> [snip] >> >> > I don't know how to do that mechanism... but if we knew where to trap >> > filesystem writes, we could simply freeze at that point, and at that >> > point only, no? >> >> Any operation at all that has an external effect must not occur after >> the snapshot is made; otherwise, there will be random hard-to-find >> corruptions and other problems occurring as a result. Thus, for >> example, any writes (either directly or indirectly through e.g. a >> filesystem) to non-volatile storage, any network traffic, any >> communication with hardware like a printer must be prevented after the >> snapshot. > You have forgotten one critical point: The writes to save the snapshot > image must be allowed. That's what makes it really hard. Well, I didn't forget about that, although my language may have been a bit ambiguous. I was referring only to the operations that are done by normal (i.e. non-hibernate) portions of the system and which are not explicitly for the purpose of hibernating the system. It is very difficult to maintain this guarantee while also attempting to reuse the same infrastructure that is supposed to not be processing any "normal" requests in order to write the snapshot. The kdump approach handily avoids this problem by *not* reusing the same infrastructure while still allowing complete flexibility (i.e. not depending on a drivers/suspend/ide-simple). -- Jeremy Maitin-Shepard