lkml.org 
[lkml]   [2003]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Fix SWSUSP & !SWAP
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


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

\
 
 \ /
  Last update: 2005-03-22 13:35    [from the cache]
©2003-2011 Jasper Spaans