[lkml]   [2003]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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.



    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:35    [W:0.023 / U:13.800 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site