[prev in list] [next in list] [prev in thread] [next in thread] 

List:       swsusp-devel
Subject:    R =?ISO-8859-1?Q?=E9?= p : Re: [swsusp] swsusp for 2.5.1
From:       "Jose' Manuel Pereira" <jmp () asterix ! ist ! utl ! pt>
Date:       2001-12-27 21:50:11
[Download RAW message or body]

  f> ________________ En-tête réponse_______________ Objet : Re: [swsusp]
  f> swsusp for 2.5.1 Auteur : Franck SICARD <franck.sicard@3demi.net> Date :
  f> Tue, 25 Dec 2001 15:29:46 +0100

  f> if you have four mounted ext3 filsystems, then i think that this are the
  f> four kjournald process assosiatedx to the ext3 filesystems

  f> Franck

"f" == fchabaud  <fchabaud@free.fr> writes:

  f> You are right. I have however very bad news for ext3 users. As I said
  f> before, my ext3 root inode was smashed out. (...)

  f> What is rather nasty is that those problems occured under standard
  f> kernel, not patched one. This suggests really vicious alteration of the
  f> filesystem when suspending.

  f> Florent

This is rather surprising. Whatever happens to kjournald at suspending time,
it shouldn't smash the superblocks... Except if it was stopped in the process of
updating it (a rather unfortunate coincidence) -- or your rebooted system does
not understand ext3/ext2 superblocks (unlikely, worth checking?).

I suggest booting from a non-journaled filesystem, until we understand what's
wrong w/the current suspending process. Remember that the reboot brings up a
kernel unaware of any suspended state. Only after being ordered to fetch the
previous state from swap is safe to generally access all those filesystems.

One is usually able to get away w/an unclean root fs because we mount it ro
and is able to fetch initial programs from it. If that is impossible, the
situation above described arises...

Having a minimal fixed (ro) root seems to be the safest way.

One thing that is critical to ensure is that all writing activity to any disk
is finished before starting suspending and swapping all pages.

One thing I still don't know how to guarantee is that all DMA driver activity
is done -- only then can we proceed to suspend processes like kjournald...

Let's recapitulate how the whole process should go:

1) Freeze all user processes
2) Swap all those to disk
3) Wait for kernel threads, tasklet, whatever in the kernel may write to disk
   or change pages in memory. This probably includes all network drivers,
   etc., and everything that allow h/w to DMA.
   This step is quite tricky. Probably only allowing reasonable timeouts may
   give any guarantee (safety) here.
4) Proceed to write kernel data pages to swap. Here, the process is known, but
   not the dependency to 3) above.

Having done all above, the resuming process is quite easy. Even when you have
journalling fs's replaying, you'll be safe, since replaying is monotonic
(replaying twice is harmless).

Comments?

-- 
 Jose' Pereira		(CIIST sysadm)			Tel. +351.21.841 7526
 Centro de Informatica
 Instituto Superior Tecnico - Technical University of Lisboa
 Av. Rovisco Pais - 1049-001 Lisboa - Portugal

_______________________________________________
swsusp maillist  -  swsusp@lister.fornax.hu
http://lister.fornax.hu/mailman/listinfo/swsusp
[prev in list] [next in list] [prev in thread] [next in thread]