Systemd-swap: Hibernation really not possible?

@TeslaBargain, some kind of black voodoo magic.

Of course that possible to make it on your own - so you can do it your self.

For zram, you need make all that things happen before hibernation:

1. Add new swap file
2. Format it & swapon
3. Add all info to access data in swapfile to kernel cmdline (change grub config, or systemd-boot, or lilo, or u-boot & etc?)
4. Swapout zram
5. Hibernate (i think you don't know how much time you lost before all of that happen, to make hibernation possible)
6. After reboot/exit hiberntation, you must do all that things in reverse order.

And that will only work on fs which support that kind of swap files, i.e. for btrfs that not possible.

@Nefelim4ag, thanks for letting me know, so overall too much work to make it worth it. With an out-of-the box solution I'd use it, but that way I'll just stick to my swap partition and regular swap + hibernation use.

What if there was an option to format & swapon enough swap files for the system to hibernate all its available memory when systemd-swap starts up? and perform bootctl calls, or used some kind of fixed location to test, for info to access data in swapfile to kernel cmdline in systemctl-boot or rEFInd or grub or whatever?

That way, the only real lag would be in swapping out zram, something that's just an inevitable part of using zram.

The way I figure it, if you're already going to pre-allocate swap at startup, you might as well allocate enough to be useful.

Hi. I'm willing to know if the scenario where you define a swap partition at installation and use that one for hibernation (not sure how to indicate kernel to use that only for hibernate) and then using zram for the rest of swap operations (and gain in performances). Is it something to consider? Any thoughts?

EDIT: this https://gist.github.com/klingtnet/c972b8182e4e2818d6d551b0cbeac44b
plus systemd-swap (zram)

I think one can achieve this through swap priorities + hooks for systemd hibernation. Quickly scouring various stackoverflow questions didn't answer this so I'd have to manually test it. This is actually a much easier fix than the one that I was thinking for and therefore might get implemented prior to 5.0 (although the full fix should be in 5.0)

IIRC, hibernation requires a single swap device, so it must be large enough to store all allocated memory in RAM/swap elsewhere? (but this hibernation image that is written should by default be using compression with a target of around 40%).

I have not attempted such myself, does hibernation not retain the swap files on disk or zram device(s) in RAM as if those were allocated like any other software? You're resuming a system state, so long as the memory is written into the hibernation image it should restore/resume the previous assigned swap devices instead of having to initialize them like a fresh boot would? Thus no swap off/on should be required beyond toggling a hibernation swap device?

I've only ever hibernated with a single swap device (no zswap or zram). I am not sure what happens to disk swap (as in more than one swap device exists) in that case (if it needs to fit into the hibernation image, that'd seem redundant?), likewise I assume zram would have it's allocated memory written to the hibernation image like any other memory allocated by software, not sure how the swap part is handled, if additional swap devices need to be written into the hibernation image, then I guess zram and the cache of zswap in RAM would decompress and upon resume need to be recompressed.

I'm not able to test the scenario atm to know what happens. Probably not too difficult to test via VM?

Worth noting, most distros that are using systemd should defer hibernation to systemd-sleep hibernate these days afaik? Since 2019-2020 ( in v239+ release I think?) has the ability to resume from hibernation without requiring kernel params to specify the target swap device (partition only in this case iirc), and will guess which swap device to use implicitly. If there's only one swap partition then that should be reliable without any need to set/update resume (and resume_offset if using swap file) kernel boot params.

Again, not something I've tested yet to verify.

Upstream tracking issue: https://github.com/systemd/systemd/issues/16708