别再建 swap 分区了，改用 swap 文件
Stop making swap partitions–use swap files instead
swap 文件在性能上早已与 swap 分区无异，这一事实已存在超过 20 年，但许多 Linux 发行版在安装时仍默认推荐分区方案。swap 文件在创建、调整大小、移除和修改方面都更加灵活便捷，无需重新分区即可动态管理。无论是使用 fallocate 快速分配空间，还是通过 mkswap 格式化并挂载，整个过程简单高效。对于 btrfs 用户，甚至可以直接使用 mkswapfile 命令一键完成。与其固守过时的分区习惯，不如拥抱更现代、更灵活的 swap 文件方案，让系统管理更轻松。
swap 文件在性能特征上与 swap 分区完全一致，这一事实已存在超过 20 年。
HN 评论区
239- rini17
改用 zram 吧。这是我正在用的这台破 8G 内存的多媒体/浏览迷你 PC 上的做法。SSD 速度很慢，浏览器又特别吃内存，所以比用磁盘 swap 好多了。
$ zramctl
NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 zstd 3G 482.9M 86.7M 91.8M 4 [SWAP]
- weinzierl
曾经有一段时间，不仅操作系统为了最佳性能需要分区（swapfiles），应用程序也是如此。
90 年代末，数据库通常被配置为将数据存储在原始分区上。还有其他类型的应用程序也需要分区，但对于数据库来说，这真的很常见。
这种做法直到操作系统允许应用程序绕过常规文件系统缓存后才真正消亡。
在 Linux 中，这就是 O_DIRECT，有趣的是 Linux 加入这一行列非常晚，因为 Linus 对此深恶痛绝。当然，他绝不是唯一一个持这种观点的人，至少 Alan Cox 和 Andrew Morton 就持怀疑态度，其他人也是。Linus 对此的态度异常极端，那场特定的讨论大概也是人们用来攻击他的大部分引语的单一来源。
- cesarb
> fallocate / chmod / mkswap
为什么不直接用 "mkswap --size ... --file ..."，它不仅能完成这三件事，还能做更多？例如，根据 mkswap 的手册页，"[...] 为新创建的文件设置 nocow 属性 [...]"，而这个细节似乎在这个 gist 中缺失了。
- ghostly_s
我宁愿听我操作系统供应商的，而不是听这个链接都挂了的随机 GitHub 用户，谢了。
（我没兴趣接受这方面的教育，我有更重要的事要做。有意见去找 Debian 说吧。）
- lproven
这里有几点没考虑到。
* 如果你的根分区很小，默认配置会把 swap 文件放在那里，浪费宝贵的空间。
* 使用分区时，更容易将 swap 放在单独的物理设备上，这对性能有好处。
* 如果你像我一样，经常在一台机器上双启动 2 个或更多 Linux 发行版或安装，你可以毫无问题地在不同发行版之间共享一个 swap 分区。这意味着更节省空间，也降低了分区管理的复杂性。
* 当然还有休眠功能，正如其他人提到的那样。
结论：不，这是糟糕的建议，除非是非常简单的场景。
- SoftTalker
有一段时间，因为 RAM 容量变得非常大，我会在 Linux 服务器上完全不设置 swap。我想，如果系统已经耗尽了 128GB 的真实内存，一个 2GB 的 swap 文件又能做什么呢？
我这样做从未遇到过任何问题，但我后来了解到，Linux 理想状态下还是需要一些 swap 空间的，它会将其用于某些内部维护工作。
- kazinator
Swap 分区是你那种“设置一次，忘记它”的永久安装方案，用于日常使用。
Swap 文件则是用于“哦天哪，我得运行这个罕见的、需要大量虚拟内存的东西”的场景。你创建它们，执行 "swapon"，然后在完成后执行 "swapoff" 并删除。
- spijdar
既然可以有 swap 目录，为什么还要用 swap 文件呢？;-)
Sprite（在我看来）有一个非常有趣的 swap 解决方案。每个主机都有一个目录，通过其主机 ID 在 `/swap` 目录下引用，在该目录内，虚拟内存的各个段会被单独保存：https://github.com/OSPreservProject/sprite/blob/master/src/k...
Sprite 像现代操作系统一样过度承诺内存，并单独存储各个段，以便进程迁移能够工作（如果一个段被交换出去，swap 文件的路径在集群的任何地方都保持不变，因此如果进程被迁移，你不需要在迁移前将该段交换回来）：
eery@cherimoya [1] > cd /swap
eery@cherimoya [2] > ls
1 10 11 12 13 14 15 16 17 2 3 4 5 6 7 8 9
eery@cherimoya [3] > ls 3
1 113 129 148 161 172 185 20 218 238 252 33 48 63 77 95
100 114 130 15 162 173 186 203 219 24 253 34 49 64 8 96
101 115 132 150 163 174 187 204 22 240 254 36 50 66 80 97
102 116 133 152 164 175 188 205 221 242 255 38 51 67 81 98
103 117 134 153 165 176 19 207 222 243 26 39 52 7 82 99
104 12 135 154 166 177 190 209 225 244 27 4 55 70 85
105 121 139 155 167 179 191 21 226 246 28 40 56 71 86
106 122 14 156 168 180 193 210 227 247 29 42 57 72 87
107 125 140 157 169 181 194 213 23 248 3 44 6 73 9
11 126 143 158 17 182 1 […]