Re: Fix SWSUSP & !SWAP

[Andreas Dilger]

On Apr 25, 2003  14:59 +0200, Pavel Machek wrote:
> > 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.
> 
> Right.

But that is happening regardless of whether a swapfile is in use or not.
It is a problem whether the filesystem is journaling or not.  Basically,
if you are entering into a normal boot sequence and mounting filesystems
and then resuming from your saved state you risk filesystem corruption.

The only way to avoid that would be for the kernel to detect the swsusp
magic data in the swap partition _before_ any filesystems are mounted
(probably via initramfs), and then resume from that image (which will
implicitly "mount" the filesystem because it was never unmounted in
that image).  Then, swsusp becomes a special case of the 2-kernel-monte
(or add your other favourite kernel-booting-kernel method here), where
most of your kernel state is swapped out and only a limited recovery
state is loaded into RAM before doing the kernel dance).

> > > If that is the case, then the only way to avoid this would be to call
> > > sync_supers_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.
> 
> When I do sys_sync(), will it trigger that?

No, having sys_sync() do journal purging would really hurt journal fs
performance.  That's why I said you need to call sync_supers_lockfs(),
which is unfortunately not in 2.4 kernels (available in the LVM CVS
as a patch), but it does appear to be in 2.5 kernels.  For journaling
filesystems this is the equivalent of temporarily unmounting the
filesystem and then remounting it when unlockfs() is called.

Note that you must explicitly pass a block device to lock, so that you
do this before shutting down the disk device.  I've never tested, but
locking the filesystem probably does not prevent writing to an existing
swapfile on that filesystem, since the swap code bypasses the filesystem
entirely.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/