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/