Re: Fix SWSUSP & !SWAP

[Nigel Cunningham <ncunningham@clear.net.nz>]

On Fri, 2003-04-25 at 09:46, Andreas Dilger wrote:
> 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.

> If the filesystem was not unmounted and remounted, then no replay will happen.  
> End of story.  If the suspend code is doing something like:
> 	
> 	1) save memory contents to disk
> 	2) suspend/power off
> 	3) reboot kernel, mount filesystem(s), etc

This is just reboot kernel. Filesystems aren't mounted before (4).

> 	4) check for presence of suspend image
> 	5) replace currently-running kernel with suspended kernel
> 
> Then you are in for a world of hurt regardless of whether the data is in a
> swap file or a swap partition.  The data in the swapfile isn't touched by
> journal replay at all (so that is safe regardless), but the rest of the
> filesystem is, which could cause strange disk corruption since the in-memory
> data doesn't match the on-disk data.

On the second part, "Precisely."

> 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.

Regards,

Nigel