Message-Id: <201009300956.29993.Martin@lichtvoll.de>
Date:	Thu, 30 Sep 2010 09:56:28 +0200
From:	Martin Steigerwald <Martin@...htvoll.de>
To:	Nigel Cunningham <nigel@...onice.net>
Cc:	tuxonice-devel@...ts.tuxonice.net,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux PM <linux-pm@...ts.linux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"TuxOnIce-devel" <tuxonice-devel@...onice.net>
Subject: Re: [TuxOnIce-devel] Nigel's current for-rafael queue

Am Dienstag 28 September 2010 schrieb Nigel Cunningham:
> Hi Martin.

Hi Nigel.

> On 29/09/10 05:45, Martin Steigerwald wrote:
> > Am Samstag 25 September 2010 schrieb Nigel Cunningham:
> >> Hi Rafael.
> > 
> > Hi Nigel,
> > 
> >> Please find attached a slightly updated version of the patchset I
> >> sent a few months ago. The main change is that I've prepended and
> >> additional patch which lets the user see the speed at which the
> >> image is being read and written. This is accomplished by recording
> >> the MB/s in a single byte in the image header, and using a couple
> >> of __nosavedata variables to get the data back through the atomic
> >> restore. I realise the char limits us to 255MB/s at the moment. In
> >> future patches, I intend to address this by storing the data in a
> >> 'proper' image header (it's a real problem - TuxOnIce reads and
> >> writes on the same set up at speeds around 250MB/s).
> > 
> >> Results on my Dell XPS M1530, which has an SSD hard drive are:
> > I found one issue with this patchset or more precise I think with the
> > state of in-kernel-suspend before:
> > 
> > I accidentally booted a kernel without your patches and it didn't
> > seem to stop on the hibernation image from the kernel with your
> > patches. Well I let my laptop unattended for a little while, so when
> > there has been a (short) timeout, I might have missed that message.
> > 
> > I lost a hibernation image this way which caused successful journal
> > replay on my Ext4 filesystems.
> > 
> > Does a kernel without your patches offer to reboot into the correct
> > kernel, then it finds a hibernation image from a kernel with your
> > patches?
> > 
> > If not, I think for the future it should give a warning with a quite
> > high timeout, and offer to reboot into the right kernel.
> 
> My patches only focus on the I/O code in swsusp at the moment. I know
> there are still tons of things from TuxOnIce that could be put into
> swsusp, but at the moment I'm just focusing on I/O code.
> 
> The answer at the moment is therefore "I'm sorry, but if you're going
> to try out this code, you're going to have to live without some of
> TuxOnIce's nice features until I can split them into nice little
> patches, and start trying to persuade Rafael they're a good idea to
> merge."
> 
> Sorry!

No problem. I wasn't aware that in kernel suspend does not have any checks 
like that, cause TuxOnIce and Userspace Software Suspend both have them. 
Thus I thought, that the check somehow did not trigger while it should. 
But if no check was in there, this is no problem with your patches.

I try to avoid booting from kernels without your patches when I suspend 
from one with your patches by making sure that the kernel with your 
patches is the first in grub menu ;).

I think a check should go in as soon as possible tough. Cause anything 
else just asks for filesystem corruption. I still have a "sync" in my pre 
hibernate script that calls the hibernate script. And Ext4 is good at 
recovering from journals. But still...

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

Download attachment "signature.asc " of type "application/pgp-signature" (199 bytes)

Powered by blists - more mailing lists