Systemd-swap: 休眠真的不可能吗？

@TeslaBargain ，某种黑巫术。

当然，可以自行实现它-因此您可以自己完成。

对于zram，您需要使所有事情在休眠之前发生：

1. 添加新的交换文件
2. 格式化并交换
3. 添加所有信息以访问交换文件中的数据到内核cmdline（更改grub配置，或systemd-boot，或lilo，或u-boot等？）
4. 交换zram
5. 休眠（我想您不知道在所有事情发生之前要浪费多少时间才能使休眠成为可能）
6. 重新引导/退出休眠后，您必须按照相反的顺序执行所有操作。

而且这仅适用于支持那种交换文件的fs，即对于btrfs来说是不可能的。

@ Nefelim4ag ，感谢您让我知道，所以总体而言，太多的工作值得它去做。 使用开箱即用的解决方案，我会使用它，但是那样，我将坚持使用交换分区和常规的交换+休眠方式。

如果可以选择格式化和交换足够多的交换文件以使系统在systemd-swap启动时休眠其所有可用内存，该怎么办？ 并执行bootctl调用，或使用某种固定位置进行测试，以获取信息以将swapfile中的数据访问systemctl-boot或rEFInd或grub或其他文件中的内核cmdline？

这样，唯一的真正滞后就是换出zram，这只是使用zram的必然部分。

我认为，如果您已经打算在启动时预先分配交换空间，则最好分配足够的空间来使用。

你好。 我很想知道是否在安装时定义了一个交换分区，并使用该分区进行休眠（不知道如何指示内核仅将其用于休眠状态），然后使用zram进行其余交换操作的情况（并获得了这种情况）在表演中）。 有什么要考虑的吗？ 有什么想法吗？

编辑：这个https://gist.github.com/klingtnet/c972b8182e4e2818d6d551b0cbeac44b
加上systemd-swap（zram）

我认为可以通过交换优先级+系统休眠的钩子来实现这一目标。 快速搜索各种stackoverflow问题并不能解决这个问题，因此我必须手动对其进行测试。 这实际上比我正在考虑的修复程序容易得多，因此可能在5.0之前实现（尽管完整修复应该在5.0中）。

IIRC，休眠状态需要一个交换设备，因此它必须足够大以将所有分配的内存存储在其他位置的RAM /交换中吗？ （但是默认情况下，写入的休眠图像应该使用目标为40％左右的压缩）。

我自己没有尝试过，休眠方式是否不会像其他软件一样分配交换文件到磁盘或zram设备的RAM中？ 您正在恢复系统状态，只要将内存写入休眠映像，它就应该还原/恢复先前分配的交换设备，而不必像重新启动一样初始化它们？ 因此，除了切换休眠交换设备外，是否还不需要进行任何交换操作？

我只有一个交换设备（没有zswap或zram）处于休眠状态。 我不确定那种情况下磁盘交换（如果存在多个交换设备）会发生什么（如果它需要装入休眠映像，这似乎是多余的？），同样，我假设zram会为其分配内存像软件分配的任何其他内存一样，写入休眠映像，不确定是否要处理交换部分，如果需要将其他交换设备写入休眠映像，则我猜zram和RAM中zswap的缓存将解压缩，然后简历需要重新压缩。

我无法测试场景atm以了解会发生什么。 通过VM进行测试可能不太难吗？

值得注意的是，这几天大多数使用systemd的发行版都应该将休眠状态推迟到systemd-sleep hibernate ？ 自2019-2020年以来（我认为在v239 +版本中），我具有从休眠状态恢复的能力，而无需内核参数指定目标交换设备（仅在本例中为iirc）进行分区，并且可以隐式猜测要使用哪个交换设备。 如果只有一个交换分区，那么它应该可靠，而无需设置/更新resume （如果使用交换文件， resume_offset ）内核启动参数。

再说一次，我还没有测试过要验证的东西。

上游跟踪问题： https :