Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161236AbWJXVd4 (ORCPT ); Tue, 24 Oct 2006 17:33:56 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1161237AbWJXVd4 (ORCPT ); Tue, 24 Oct 2006 17:33:56 -0400 Received: from pentafluge.infradead.org ([213.146.154.40]:1687 "EHLO pentafluge.infradead.org") by vger.kernel.org with ESMTP id S1161236AbWJXVdz (ORCPT ); Tue, 24 Oct 2006 17:33:55 -0400 Date: Tue, 24 Oct 2006 22:33:42 +0100 From: Christoph Hellwig To: Pavel Machek Cc: Christoph Hellwig , "Rafael J. Wysocki" , David Chinner , Nigel Cunningham , Andrew Morton , LKML , xfs@oss.sgi.com Subject: Re: [PATCH] Freeze bdevs when freezing processes. Message-ID: <20061024213342.GA22552@infradead.org> Mail-Followup-To: Christoph Hellwig , Pavel Machek , "Rafael J. Wysocki" , David Chinner , Nigel Cunningham , Andrew Morton , LKML , xfs@oss.sgi.com References: <1161576735.3466.7.camel@nigel.suspend2.net> <200610231236.54317.rjw@sisk.pl> <20061024144446.GD11034@melbourne.sgi.com> <200610241730.00488.rjw@sisk.pl> <20061024170633.GA17956@infradead.org> <20061024212648.GB5662@elf.ucw.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061024212648.GB5662@elf.ucw.cz> User-Agent: Mutt/1.4.2.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1911 Lines: 39 On Tue, Oct 24, 2006 at 11:26:48PM +0200, Pavel Machek wrote: > > No, that's definitly not enough. You need to freeze_bdev to make sure > > data is on disk in the place it's expected by the filesystem without > > starting a log recovery. > > I believe log recovery is okay in this case. > > It can only happen when kernel dies during suspend or during > resume... And log recovery seems okay in that case. We even guarantee > that user did not loose any data -- by using sys_sync() after userland > is stopped -- but let's not overdo over protections. You're still entirely missing the problem. Take a look at http://www.opengroup.org/onlinepubs/007908799/xsh/sync.html and the linux sync(2) manpage. The only thing sync guarantees is writing out all in-memory data to disk. It doesn't even gurantee completion, although we've been synchronous in Linux for a while. What it does not gurantee is where on disk the data is located. Now for a journaling filesystem pushing everything to the log is the easiest way to complete sync, and it's perfectly valid - if the system crashes after the sync and before data is written back to it's normal place on disk the system notices it's not been unmounted cleanly and will do a log recovery. In the suspend case however the system neither crashes nor is unmounted - thus the filesystem doesn't know it has to recover the log. We have to choices to fix this: (1) force a log recovery of an already mounted and in use filesystem (2) make sure data is in the right place before suspending (1) is pretty nasty, and hard to do across filesystems. (2) is already implemented and easily useable by the suspend code. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/