Re: Back to the future.

[Nigel Cunningham <nigel@nigel.suspend2.net>]

[-- Attachment #1: Type: text/plain, Size: 1918 bytes --]

Hi.

On Sat, 2007-04-28 at 16:45 -0700, Linus Torvalds wrote:
> 
> On Sun, 29 Apr 2007, Rafael J. Wysocki wrote:
> > 
> > OK, more precisely: fs-related threads should not try to process their queues,
> > etc., after the snapshot is done, because that may cause some fs data to be
> > written at that time and then the fs in question may be corrupted after the
> > restore.  Not all of the I/O in general, fs data.
> 
> But that's not true _either_. That's only true because right now I think 
> we cannot even suspend to a swapfile (I might be wrong). 
> 
> If you have a swapfile on a filesystem, you'd need those fs queues 
> running!

For Suspend2, and I think for swsusp too, we bmap the locations when
allocating the storage, and then submit our own bios. Even if swsusp
isn't using this method, I'm pretty sure the swap code does bmapping at
swapon time to avoid raciness later.

> > Well, I'm not sure whether or not that still would have been the case if we had
> > stopped to freeze kernel threads for the hibernation/suspend.
> 
> Did you miss the email where Paul pointed out that Mac/PowerPC didn't use 
> to do any of this? And apparently never had any issues with it? And 
> probably worked more reliably several years ago than suspend/hibernation 
> does _today_?
> 
> Ie we do have history of _not_ freezing things.  The freezing came later, 
> and came with the subsystem that had more problems..

It also came because of problems. Not working perfectly isn't
necessarily a sign of a faulty reason for being added in the first
place.

I should also add, not freezing things is fine if you're happy with
getting half an image at most. If you want a full
just-as-if-I'd-never-turned-the-power-off image, you need freezing so
that you can have some pages which can be saved before others are
atomically copied, to ensure the whole image is consistent.

Nigel

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]