11

I have computer with battery power supply that allows running the computer for approximately one minute after power loss. I want to trigger suspend-to-disk immediately after power loss so it can be resumed later. The initrd (default Devuan initrd) looks for suspend signature in the swap partition and resumes from it when the signature is found. I am not sure what happens when power is completely interrupted while writing data to the swap partition. That could happen when the battery fails or the system hangs while suspending. Will the system resume from the corrupted swap partition or it will just ignore the swap partition? I consider the second option better – it is better to have incorrectly unmounted filesystem than corrupted system state.

Is the signature written to the swap partition after or before the other data? Does it use checksums?

jiwopene
  • 1,002
  • 7
  • 19
  • Part of the question is whether the suspend procedure is careful to make sure the "suspend signature" doesn't commit to disk before any of the writes of the suspend data. Hardware *can* do this, e.g. by making sure to flush the disk's internal write cache before the signature write, or a write barrier, the same kind of write ordering that journaling FSes rely on. – Peter Cordes Feb 22 '21 at 11:03
  • (Or at least this would be the question if not for Chris's point that the next boot knows whether it's booting from a previous hibernation or not. Checks like that would seem to rule out hibernating Linux, booting another partition to e.g. play video games, then resuming Linux. IIRC, years ago Linux was more willing to resume without needing a special BIOS state.) – Peter Cordes Feb 22 '21 at 11:06
  • I expect that if the swap partition is corrupted and used, there's a very high chance the computer will just crash completely, rather than silently corrupting stuff. – user253751 Feb 22 '21 at 12:48
  • 1
    @PeterCordes Sorry, my answer was a bit unclear about the implications of S4/S5. In the case where suspension goes to S5 (which should be the case on most modern platforms), it's generally possible to go into another operating system and later resume Linux. Hopefully my update makes that clearer. – Chris Down Feb 22 '21 at 13:11
  • 1
    Hibernation has long been used as a last ditch attempt to save the state of the OS when a laptop battery is nearly empty. There's a non-negligible chance of the battery running out during the process. If this tended to cause system corruption, it would be all over the news. – TooTea Feb 22 '21 at 14:49

1 Answers1

21

If power is lost prior to explicitly entering S4 or S5 state (hereafter just referred to as "hibernation state" for simplicity), then the partially filled data in the swap partition will be ignored completely, because there's no hibernation state persisted. Swap partitions and files are also volatile, and the data in it will be ignored after a reboot without hibernation state.

In the kernel, restoration from hibernation is requested by the configured platform_hibernation_ops->leave, which is only called on resumption from hibernation state. For example, on most modern platforms where S5 is supported, we configure a reboot notifier.

Losing power prior to hibernation state being entered (and thus the hibernation file being completely written) won't have configured any hibernation to resume from, so there's no chance it will try to thaw using the partially-filled swap space. As such, you don't have to worry about the kernel trying to restore from a partially complete hibernation.

Chris Down
  • 122,090
  • 24
  • 265
  • 262
  • Linux hibernation to swap doesn't use S4 state. – Simon Richter Feb 22 '21 at 11:24
  • 1
    @SimonRichter I don't know why you think that, but yes, we do: https://github.com/torvalds/linux/blob/fef98671194be005853cbbf51b164a3927589b64/drivers/acpi/sleep.c#L883-L929. We'll also make use of S5 if it's available on the platform. If that's what you're referring to, sure, I can write S4/S5 everywhere, but that seemed fairly obvious. – Chris Down Feb 22 '21 at 12:16
  • (It should be noted that really all kinds of states could be eventually used depending on the value of `/sys/power/disk`: see `hibernation_mode` in `kernel/power/hibernate.c`.) – Chris Down Feb 22 '21 at 12:38
  • Eh? Wasn't S4 the state where the firmware is supposed to write out the image to disk and restore it ( presumably to some vendor specific hidden partition on the disk ), rather than the kernel? And no systems actually implemented it, which is why the kernel swsuspend handles it by saving it to the swap partition. – psusi Feb 22 '21 at 16:13
  • @psusi It sounds like you're thinking of S4BIOS, not S4 (which uses hibernation state provided by the OS, not the firmware). – Chris Down Feb 22 '21 at 16:43
  • If the OS has to handle it anyway, then how is there still an S4 state? The whole thing that differentiates S4 from S5 is that the firmware automatically restores the state rather than going through a normal boot isn't it? Where did I put that ACPI standard? – psusi Feb 22 '21 at 17:12
  • @psusi On modern hardware, S4 and S5 typically do almost exactly the same thing, with the only practical distinction typically being minor differences in the wakeup table (if there is even any difference at all). – Chris Down Feb 22 '21 at 17:41
  • Odd... the standard appears to contradict itself. 7.3.2.5 states that when the system resumes, it performs a normal boot AND transfers control to the OS via firmware_waking_vector, but that isn't possible since the OS isn't in memory at this point. 16.3 says that after a hardware reset, power on sequence, or resume from S4, control is passed to the OS boot loader, and only for S2 and S3 is firmware_waking_vector used. I wonder if there's no difference between S4 and S5, and the kernel will use S5 instead of S4 is not provided, why would any system bother providing an S4? – psusi Feb 22 '21 at 18:44