[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: New hibernate shows strange behaviour



On Thu, 24 Feb 2005 16:52:41 -0300, Otavio Salvador wrote:
> || On Thu, 24 Feb 2005 12:44:06 +0100 (CET)
> || Andreas Tille <tillea@rki.de> wrote: 
> 
> at> On Thu, 24 Feb 2005, Otavio Salvador wrote:
> >> While I was looking for swsusp2 I found a interesting entry in FAQ
> >> about booting with normal kernels. I'm attaching it here:
> >> 
> >> http://softwaresuspend.berlios.de/HOWTO-4.html#dataloss1
> at> Sure, this perfectly descirbes the situation.  But IMHO it would be better
> at> if the SwSuspend2 would flush all write operations and work down the
> at> journal of your file system to minimize the potential data loss.  While
> at> I perfectly know (even before reading the FAQ) that I did something stupid,
> at> it is IMHO much better to have a consistent file system at all times when
> at> your computer is switched of.  Please correct me if I'm wrong.
> 
> But in this case, it's not swsusp2 failt but hibernate script fault. I
> think you can hack it to do a sync before hibernate the system and
> then you solve this issue. The problem described there isn't it but
> the wrong use of swap when you did a suspend and try to load it with a
> normal kernel...
> 
> I'm wrong?

Flushing all pending writes/journal entries is a good idea but I don't
think it will solve the problem.  The suspended kernel may also have
clean disk blocks cached in memory when you suspend.

You may boot another kernel and change a file, which resides on one of
these blocks the suspended kernel has cached.

Then boot back into your suspended kernel.  Load up one of these files
and edit it.  The suspended kernel may find its old copies of those
blocks in the block cache, and think they are clean.  If you make
edits and write them out you'll overwrite the changes that happened
while the other kernel was booted.

I suppose this could also happen with filesystem metadata
structures... the suspended kernel may have blocks cached which
correspond to filesystem data structures instead of user data... if
old versions of those blocks get changed in memory and then written
out, it could be the end of your filesystem.  

I don't know that any of this actually happens -- I'm just guessing.
Maybe SwSusp2 flushes all block caches (not just pending writes, but
cleans out caches completely).  Somebody please correct me if I'm
wrong.

-Steve



Reply to: