Geek Blight

Suspending to disk is the "simplest" way of suspending a computer, also called "hibernation". The operating system kernel stops what it is doing and writes the contents of the system RAM to a specific place in the hard drive. When a computer is running, the system memory contains all the information needed for it to run. It contains the kernel image, the kernel data structures that allow programs to run, the state of the programs currently running on the computer, etc. To sum up, a lot of data that represents the state of the computer at a given moment. By writing those contents to the hard drive, the operating system is writing a snapshot of the system in that moment to a safe place. After writing that snapshot, if proceeds to power off the machine in the same way it normally powers off.

There’s no need for special or unusual hardware support as far as I know (please, mail me if I’m wrong). If you can power on and off normally, you should be able to suspend to disk, provided you have enough space in your hard drive to store the RAM image and your OS kernel has suspend to disk support. When the computer powers on again, it checks if there’s a saved image. If there is, it restores the contens of that image to the system RAM, and continues execution at the point it left. Like if you had never turned it off. It’s not that simple because there are some things that won’t work after resuming. For example, if you suspend for a long time, which is usually the case, the network connections probably won’t work after resuming and will need to be reestablished. In other words, the computer can deceive itself and assume it’s not been powered off, but other computers will probably notice. There are some more issues. For example, when the computer boots again, it’s a normal boot up to the point when the operating system kernel starts restoring the image. First comes the BIOS, then the bootloader loads the kernel and the kernel starts booting, which is when it checks if there’s a saved image. But…​ what if you had upgraded the kernel and when it boots again, the new kernel is loaded? Or what happens if you change some hardware while the computer is suspended? Or what if you boot another operating system, maybe from a live-CD, and touch the filesystems or repartition your hard drive? A disaster. In many of these cases, as the Linux software suspend documentation says, you can "kiss your data goodbye". So be careful and always power off or reboot normally when you want to do these things. This is specially critical about kernel upgrades, which is the most common operation from those mentioned. After installing a new kernel, reboot immediatelly to load it.

That said, many Linux distributions have suspend to disk preconfigured and handle that common kernel upgrade case. When you install a new kernel, maybe a "flag file" is created somewhere and when you try to run one of the suspend-to-disk scripts, they detect the flag file and refuse to suspend. In any case, it’s always a good idea to reboot after installing a new kernel. Furthermore, if you have installed it, you want to use it, don’t you?

To suspend to disk under Linux you don’t really need any special software package as long as your kernel has been passed the appropriate parameters on boot (resume=…​) and you do the right thing. Essentially, you need to specify a swap partition to save to and restore the disk image from, and then run a couple of things:

But there are more ways to do it (s2disk), and you probably need to run a couple of things before and after suspending. This is because, like I mentioned, not everything is restored properly. Most people would want to bring down the network interfaces before suspending and bring them up after resuming, etc. Also, some kernel modules and programs don’t like suspending (proprietary NVIDIA kernel module maybe?), and you may also need to reload and relaunch those kernel modules and programs. For example, my Acer laptop has a winmodem that uses the snd_intel8x0m kernel module and the slmodemd daemon. They need to be reloaded, so I have to kill the daemon, unload the module, reload the module and restart the daemon when I suspend. For this reason, and because I use Slackware and need to handle all of this myself, I created a short (24 lines) suspend-to-disk shell script that automates everything, and it’s the one I call if I want to suspend to disk.

If, instead of the vanilla kernel software suspend to disk you’re using Suspend2, you should probably configure your hibernate script and use it, because it may be easier. Remember to read your distribution manual and see what they have done for you and how everything is set up. This way you’ll know what you need to run if you want to suspend to disk.

In terms of time and power, suspend-to-disk isn’t specially fast, but it’s worth using it unless you can suspend to RAM. When the computer powers off, it really powers off. You may even unplug it if you want, and it won’t drain the batteries in case it’s a laptop computer. The time it takes to save and restore the image on disk depends on several factors, which are usually your disk speed, your CPU speed and if you’re compressing or encrypting the image or not. Even though it sounds weird or unintuitive, it’s usually faster to compress the image. This is because in modern computers, the CPU can compress the image faster than the hard drive can write it, so compressing it will use more CPU power but will take less time, because the amount of data to write will be greatly reduced. The same applies when resuming, because the CPU will be able to decompress the image faster than the hard drive will read it.

It will probably take around 10-20 seconds to power off and between 20 and 50 seconds to power on (around 35 in my case) since you press the power on button on the computer. A fast BIOS helps to boot faster, so does having a fast hard drive and a fast CPU. In general, unless your system is very well tuned and boots up very quickly, suspending to disk will benefit you and cut your boot time to one half or less. You will have to experiment and see it for yourself. Also, let’s not forget that when it has finished booting, you will have everything running like it was before. The disk cache will also be in place. In other words, the restored system will be as "responsive" as it was before suspending. This is another good reason for considering suspending to disk instead of simply powering off.

In terms of power, which is important if you use a laptop, I mentioned before that the system powers off really and will not drain the battery power. But let’s not forget that those 10-20 seconds in which the computer is writing the image to disk and the 20-50 seconds it takes to restore it are peaks in power usage, because the disk and probably the CPU will be working intensely. Those total 60 seconds of high power usage may use the same as 5 minutes of power being idle, or something similar, but not much more.

Suspend to RAM means to power off almost everything in the computer except for the system RAM. That way, the state of the current running system is preserved while you save power by disconnecting the CPU, the hard drive, etc. There’s no need to lose time saving and restoring great amounts of data, but simply to disconnect and reconnect components. Hence, this is the fastest method. My Acer laptop can suspend to RAM in less than 10 seconds, and be restored in that same amount of time (7.5 seconds average using a stopwatch). You can think of suspend to RAM like going into standby mode.

However, suspending to RAM needs special cooperation from the computer hardware. When you resume, it’s not a normal boot (if you can still call it "boot"), and there are many things that may go wrong. The most typical problems involve the graphics card not restoring properly, and you may end up with a blank or corrupted screen after resuming, even though the computer keyboard and mouse may still work (or may not). From the software point of view you face the same problems as when suspending to disk, that is, you’ll probably want to bring down network interfaces, unload problematic modules, etc.

For these reasons, suspending to RAM does not always work. I think you can suspend to RAM using Suspend2 but I’ve only tried the vanilla kernel software suspend using the s2ram program from the suspend package. The name of the actual package depends on the distribution, so you better check which package contains the s2ram program and install it. The program maintainers are very optimistic and they always tell you to keep trying, because s2ram has several options to try different approaches and you may find one that works. Sometimes the program may tell you your computer is not in the whitelist and refuse to run, but you can force it to try and test several different methods, and one of them may actually work, so don’t lose hope. In case you make it work with a non-whitelisted system, they ask you to report the success and the method you forced, so they can whitelist your system in future versions.

Like before, in my Slackware system I wrote a specific script for myself (23 lines), which is identical to the one that suspends to disk but replaces the 2 critical commands with one call to s2ram. It’s the one I invoke when I "close" the laptop, that is, the one associated with the LID button event.

Suspending to RAM does use some power. Remember that your memory stays connected while the computer is suspended. For reference, my laptop can survive suspended for more than 12 hours when there’s only half an hour of battery left. If you’ve got a battery that lasts for 4 or 6 hours and it’s full, the computer may well survive for several days, but not many. Of course, if it’s a desktop computer and/or you leave it plugged in, it can stay so for as long as you want or your electric company lets you. I haven’t noticed the power on and off process having any peaks in power usage. It simply powers off to "standby" and on to normal.

As with suspending to disk, the system will be as responsive as just before suspending. Due to the low power requirements and the minimum time it takes to restore the system, suspending to RAM is usually a good alternative to leaving the system idle turned on, unless you want it to keep downloading something or completing some calculations.

Suspend to both is useful if you can get suspend to RAM to work. Before suspending, it saves a RAM image to disk (like in suspend to disk) and then tries to suspend to RAM. If there’s some problem and the power is interrupted while suspended (because you run out of battery power, for example), it will restore the disk image when booting. Otherwise, it resumes like in suspend to RAM and discards the disk image. I haven’t found this useful, but I’m sure many people will do in their specific situations and environments.