Re: What's the Debian way of disabling suspend to disk?
On Fri, 3 Sep 2010 22:06:33 -0300
Henrique de Moraes Holschuh <hmh@debian.org> wrote:
> On Fri, 03 Sep 2010, Celejar wrote:
> > On Thu, 2 Sep 2010 14:32:03 -0300
> > Henrique de Moraes Holschuh <hmh@debian.org> wrote:
> >
> > ...
> >
> > > That said, I don't trust hybernation. Your data is much safer in the
> > > long run if you restrain yourself to suspend-to-RAM and shutdowns.
> >
> > Can you elaborate on this? I have certainly experienced my share of
>
> Yes. Suspend-to-disk on Linux x86/amd64 depends on fragile operations, and
> worse, it requires that the hibernation core and some of the more fiendishly
> complex kernel subsystems never disagree at all on the details.
>
> That can easily result in silent, hard-to-track data corruption when code
> changes. When you're very lucky, it hoses the kernel or the filesystem
> metadata in a way which can be easily noticed by some kernel assertion,
> resulting in an OOPS or warnings. If you're unlucky, it can slowly rot away
> your filesystem or the data inside it.
>
> Restoring from an hibernation image also does nasty things to the ACPI
> firmware. But at least any problems there are much more likely to cause the
> box to fail to resume entirely, instead of truly evil stuff like silent
> filesystem or application memory space corruption.
Thanks for the explanation. I use hibernation pretty heavily, and I've
never really noticed such problems, but OTOH, I have had my share of
system crashes and other such failures, which I've always just chalked
up to living on the bleeding edge (Sid, plus git kernels from
upstream), but who knows ...
> > or do you mean the much more serious problem of the hibernation image
> > becoming corrupted and the system not realizing this? I though that
>
> It is not the hibernation image getting corrupted. It is running system
> state getting corrupted due to bad interaction between parts of the kernel,
> or outright kernel bugs.
>
> Suspend-to-RAM is much easier to get right (and *keep* right), and far less
> fragile.
I'd love to use s2ram, but I've never gotten it to work on this
machine, even with a great deal of time and effort.
Celejar
--
foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator
Reply to: