Re: Fix SWSUSP & !SWAP

From: Pavel Machek <pavel@ucw.cz>
To: Nigel Cunningham <ncunningham@clear.net.nz>
Cc: Andreas Dilger <adilger@clusterfs.com>,
	Pavel Machek <pavel@ucw.cz>, Andrew Morton <akpm@digeo.com>,
	cat@zip.com.au, mbligh@aracnet.com, gigerstyle@gmx.ch,
	geert@linux-m68k.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Fix SWSUSP & !SWAP
Date: Fri, 25 Apr 2003 14:59:18 +0200	[thread overview]
Message-ID: <20030425125918.GA25733@atrey.karlin.mff.cuni.cz> (raw)
In-Reply-To: <1051232975.1919.26.camel@laptop-linux>

Hi!

> > On Apr 24, 2003  22:48 +0200, Pavel Machek wrote:
> > OK, then why all of the talk earlier saying that journal recovery will
> > corrupt a swapfile?  That was the reason journaling was brought into the
> > discussion in the first place:
> > 
> > 	"And now you have kernel which expects data still in journal (that was
> > 	 state before suspend), but reality on disk is quite different (journal
> > 	 was replayed). Data corruption." -- Pavel
> 
> I don't believe Pavel was saying the image would be corrupted. Rather,
> the rest of the disk contents are corrupted by replaying the journal and
> then resuming back to a memory state that has been made inconsistent
> with the disk state because of the journal replay.

Right.

> > If that is the case, then the only way to avoid this would be to call
> > sync_super_lockfs() on each filesystem before the suspend, which will
> > force the journal to be empty when it returns.  That API is supported
> > by all of the journaling filesystems, and is probably a good thing to
> > do anyways, as it will potentially free a lot of dirty data from RAM,
> > and also ensure that the on-disk data is consistent in case the resume
> > isn't handled gracefully.
> 
> Sounds like a good idea to me.

When I do sys_sync(), will it trigger that?
								Pavel
-- 
Horseback riding is like software...
...vgf orggre jura vgf serr.