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

List:       swsusp-devel
Subject:    R =?ISO-8859-1?Q?=E9p_:_R=E9p_:_R=E9?= p : Re: [swsusp] swsusp for
From:       fchabaud <fchabaud () free ! fr>
Date:       2001-12-31 14:51:16
[Download RAW message or body]


fc> And it didn't smash them, only the root inode. But fsck does it on fc> reboot.

> A lost root inode probably means a fscked superblock...

Probably.

fc> All the kernels I used were ext2 and ext3 enabled. The rescue system was fc> a \
2.4.16 unpatched kernel. The only difference was that the partitions fc> were marked \
as ext2 in the fstab file. But this should not be a problem fc> since an ext3 \
partition can be mounted as ext2, isn't it ?

> It can. BUT: always use fsck -j nevertheless!!! (to replay >the journal) Or \
> else...Well, you saw what can happen :-}

OK, I missed that. I made fsck, and after that tune2fs -j. However, this should NOT \
cause a problem, because if you use a rescue kernel like SuSE's 7.2 it has not ext3 \
support compiled in and the ext2 utilities cannot deal with journal. The ONLY \
acceptable behaviour for ext3 is therefore to be compatible with ext2 and to be able \
to recreate a journal by its own.

fc> I agree with you. The discussion with Pavel suggests however that the
fc> bug may be elsewhere and revealed by suspension patch (and perhaps even
fc> with higher probability of occurence with ext3)

> If you didn't use "-j", it's not a bug, it's a documented >possibility \
> (seee2fsprogs docs). (Alright, personally, I >have done that a couple of times, \
> onlyI've been lucky...)

See above. I had read the e2fsprogs docs, but I had not seen that omitting -j on an \
ext3 partition could lead directly or indirectly to destruction of superblock.

fc> And what about initrd ? This would be a good mean to have a stable root
fc> from which to resume. By the way, what kind of linux loading is used by
fc> testers ? This could give hint in searching the bug if initrd users
fc> never experience problem suspending.

> Excellent idea! I stand corrected: an initrd root IS the >safest way.

> I never used initrd, but seems the best to test this kind >of reboots. Also, \
> Isuggest mounting only a scratch >partition containing a minimal installation, to \
> prevent losing important files (yes, I know everyone >keeps excellent backups ;-) \
> But).

Actually my rescue system is an initrd, so it may not completely prevent losing \
important files :-(

An initrd may however help dealing with the fact that kernel doesn't know about \
suspension on reboot. What would be necessary is a linuxrc script that will NOT be \
called on reboot (because resuming will occur before) and only deal with normal \
reboot or noresume option. This will prevent kernel from using disk before starting \
resuming since the root partition will stand in memory. The linuxrc script would have \
another advantage: fsck could be done on unmounted root partition if the necessary \
utilities are inserted on the ram initrd.

fc> For myself DMA was disabled for the disk. There is also a kernel option
fc> to disable DMA.

> There are other devices that do DMA. Agreed that the >disk is the mostinteresting. \
> Perhaps the suspend >process could include ensuring that DMA is off before starting \
> the freezing.

A timeout ? ;-)

fc> For myself apmd daemon stops problematic daemons. I however disagree
fc> with you concerning timeout because this is not a solution. A timeout
fc> scheduled for an architecture may be unsufficient in another
fc> configuration.

> Well, for "reasonable" I meant an immensely >exaggerated time, like 1 sec. orso... \
> Should work on any >of the archs linux was already ported to, I think :-)

> Ok, is 3 secs enough? Please note that we're going to >switch off the damn
> thing, so blindingly fast speed is not that important...

I agree that fast speed is not important. My concern is more a matter of principle. \
Inserting a timeout is the sign that we can't understand clearly the cause of problem \
;-)

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

fc> This is what everyone think. But is that implemented this way (see
fc> discussion with Pavel) ? It would worth to check that also...

> Yes, Pavel even has included code to prevent that for >reiserfs. But I don'tagree \
> that's needed. NB: I haven't >delved into reiserfs&ext3 or other jfs'sreplay code. \
> But, by >definition of journalling, I wouldn't expect to findanything in >contrary.

So am I... but something must have caused the crash.

> Hope you can recover your system,

I have some backups... all I need is a distro. Tried to buy one yesterday at \
Marseilles but all SuSE Pro were sold out. Hey Pavel, Christmas seems to have been a \
good day for SuSE :-) Anyway, I'm confident with that, just a matter of patience.


Florent.




_______________________________________________
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]