On Apr 24, 2003 22:48 +0200, Pavel Machek wrote:
> Andreas Dilger wrote:
> > Wouldn't that be true in all cases where you have a journaled filesystem
> > and you suspend?
>
> No. In normal state you restore without mounting anything (thus no
> journal replay).
>
> > Are you talking about someone restarting system (without
> > doing a resume), mounting the file system (causing journal replay), and
> > then shutting down and going back to the suspended image?
>
> No, I'm not.
>
> > I think the important thing to note is that if you don't unmount the
> > filesystem during suspend, then no journal recovery will take place
> > at resume time, because you are not really mounting the filesystem
> > at all. And I can't see how you could be unmounting the filesystems
> > without killing all of the applications, at which point it would make
> > suspend pretty useless.
>
> No, I'm not unmounting it.
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
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
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.
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.
> > What is also important to note is that during normal filesystem operation,
> > the ext3 journaling code never reads back any data from the journal, with
> > the exception of a couple of fields in the journal superblock. I would
> > hazard a guess that if you did a suspend, wiped the journal, and then
> > resumed the journaling code wouldn't know the difference.
>
> That's possible, but I do not want suspend to know about filesystem
> specifics.
This was just given as a counterexample saying that the in-kernel ext3
journal code does not actually care what is in the journal on disk, since
it is never read unless there is a crash. So, the suspend code does not
need to know anything about the filesystem specifics at all in this regard.
Cheers, Andreas
-- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/- 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/
This archive was generated by hypermail 2b29 : Wed Apr 30 2003 - 22:00:18 EST