☰

两个交换文件，休眠工作，如何正确配置休眠以避免空间不足或以某种方式失败

tag-icon • tag-icon ssd swap hibernate
两个交换文件，休眠工作，如何正确配置休眠以避免空间不足或以某种方式失败

我已经配置了休眠状态，它可以正常工作，只是为了确保它不会在某些时候失败 - 这个问题。

我在不同设备上有两个交换文件，第一个是 SSD 上的小交换文件，第二个是 HDD 上的与 RAM 一样大的交换文件。Hibernate 配置为小交换文件。目前它运行良好，因为 Hibernate 并不总是需要太多（不是所有东西都写入或压缩，我不知道）。

如何配置 Hibernate 以使用两个交换？或者它会自动处理它们，不需要执行任何操作？在内核选项中，我已设置了第一个小交换，如果它先使用它（速度最快），然后再使用它，那就太好了。
我不想让 SSD 交换更大，因为 SSD 很小。

leonid@DevSSD:~$ grep resume < /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="no_console_suspend initcall_debug resume=UUID=050f8852-d8f6-4979-a4e4-c3d9b981bee9 resume_offset=34816"

/etc/fstab

UUID=050f8852-d8f6-4979-a4e4-c3d9b981bee9   /   ext4    relatime,grpquota,data=ordered,usrquota,rw,errors=remount-ro,quota  0   1
UUID=3bcf1591-7033-416a-addf-9cf8e2e10c93   /home/leonid/hdd    ext4    defaults,rw,errors=remount-ro   0   1
/swapfile                   none    swap    sw  0   0
/home/leonid/hdd/swapfile   none    swap    sw  0   0
UUID=26DA-1C76  /boot/efi   vfat    defaults    0   1

更新：我已将交换空间缩小，以便进行测试和设置优先级。休眠不会转到优先级更高的交换空间：

leonid@DevSSD:~$ swapon
NAME                      TYPE SIZE USED PRIO
/swap64k                  file  60K   0B    1
/home/leonid/hdd/swapfile file   8G   0B  100
leonid@DevSSD:~$ systemctl hibernate
Failed to hibernate system via logind: Sleep verb not supported

答案1

简而言之，您不必使用单个文件或分区进行休眠。

总结

基本内核文档中没有关于睡眠状态或者电源接口这表明交换必须在单个文件中。事实上，有迹象表明休眠数据已写入计算机上的可用交换空间：

然而，进一步的探索让我们发现swsusp 的文档其中有一个简短的常见问题解答部分，以及引文

问：swsusp（到磁盘）是否只使用一个交换分区，或者它可以使用多个交换分区（将它们聚合到一个逻辑空间）？

答：抱歉，只有一个交换分区。

虽然这只是直接针对分区我肯定会将此解释为适用于交换空格在您的机器上。

您的潜在问题是“如果我的交换文件没有足够的空间怎么办”。在这里我们遇到了一些模糊之处。文档向我们保证，系统将默认尝试创建一个关于内存大小的 2/5：

/sys/power/image_size 控制休眠图像的大小。

可以将其写入一个表示非负整数的字符串，该整数将用作图像大小的尽力上限（以字节为单位）。休眠核心将尽力确保图像大小不超过该数字。但是，如果无法实现，仍将创建休眠图像，并且其大小将尽可能小。特别是，将“0”写入此文件将强制休眠图像尽可能小。

但是文档并未指出如果映像超出交换大小会发生什么情况。我自己的经验是，当我意外关闭交换并尝试休眠时，什么也没有发生。

后续编辑

这是否说明了我（Ubuntu 用户或 Linux 用户）的情况？

我很好奇如果交换文件太小会发生什么，所以我创建了一个 44KB 的交换文件（有效！）并尝试休眠：

chick@dad:~$ swapon
NAME   TYPE SIZE USED PRIO
/swap2 file  44K   0B   -2
chick@dad:~$ sudo systemctl hibernate
Failed to hibernate system via logind: Not enough swap space for hibernation

我通过使用两个交换文件进行了进一步的测试，其中较小的交换文件优先级较高：

chick@dad:~$ sudo swapon /swap2 -p 1
chick@dad:~$ sudo swapon /swapfile -p 2
chick@dad:~$ swapon
NAME      TYPE SIZE USED PRIO
/swap2    file  44K   0B    1
/swapfile file  16G   0B    2
chick@dad:~$ sudo systemctl hibernate
Failed to hibernate system via logind: Not enough swap space for hibernation

答案2

我的个人经验是：交换分区比可用内存小并没有什么问题，但是在 Debian Buster 中，如果您只有一个交换文件，systemd 似乎会失败，并且必须正确设置交换设备的优先级。 最新版本的systemd似乎正在使用交换区域最低恢复优先级（可能是为了避免在有可用交换但最高优先级分区已满的情况下失败）。此外，如果我没记错的话，让系统分配优先级（在负范围内）不工作（请随意证明我错了...）

我不确定交换文件是否有助于将恢复映像放入小交换分区中，或者是否在恢复设备选择中引入了错误 - 我不记得我是否真正验证了哪个设备用于恢复，我确信的是它是一种回归（暂停在上次操作系统升级之前在相同条件下工作）并且设置交换设备的优先级确实解决了这个问题。

使用韋斯特的s2disk工具没有这个问题，我相信 pm-suspend 也没有。

例如，这是我的交换配置（fstab） - 16G RAM（始终完全使用）、4g 交换分区和 16g 交换文件：

UUID=58e3097b-cd76-4d9b-a46b-98aa07590f8e none            swap    sw,pri=0        0       0
/swap                                     none            swap    sw,pri=1        0       0

通过为分区设置较低的优先级（由 UUID 标识），systemd将能够正确恢复。删除交换文件将导致挂起阶段出现错误（交换区域太小），删除分区或不按所示设置优先级将导致恢复失败（initrd 无法找到正确的恢复交换卷）。

我不确定是什么决定了恢复映像的大小，但内核通常会尝试使用不超过总 RAM 的 2/5。文档对此有点含糊；它确实说恢复映像必须适合恢复交换卷，但没有说明它包含什么以及何时可以利用映像本身以外的其他分区。话虽如此，请记住

  1. 你的交换文件将能够释放内存和主分区交换空间，因此它会有所帮助
  2. 内核使用压缩；生成的图像要小得多
  3. 我怀疑最小的恢复映像主要是内核内存，并且应用程序可以交换到其他交换分区 - 就像你运行了一个占用大量内存的程序并在挂起之前将其终止一样。

最新的 systemd 代码明确支持在交换文件上设置恢复；我不确定它是多久前添加的，也不确定我是否正在使用它，或者只是将恢复图像放入小分区中，但它确实适用于此设置。

内核的文档中有很多有用的文档力量目录。您也可以使用韋斯特，如果您仍然需要由systemd您也可以覆盖systemd-hibernate.service以进行调用s2disk。

相关内容