1. 为什么 Ubuntu 20.04 用户突然开始关心“подкачка”——一个被低估的系统稳定性开关“подкачка”是俄语中“交换空间”swap的直译这个词本身不重要但它背后指向的是 Ubuntu 20.04 系统在内存吃紧时能否不卡死、不崩溃、不丢数据的关键机制。我第一次在客户现场遇到这个问题是在一台 4GB 内存的旧笔记本上部署 Python 数据分析环境跑着 Jupyter Notebook、加载 Pandas 处理 50 万行 CSV、后台还开着 VS Code 和 Chrome —— 系统突然完全无响应鼠标不动、键盘失灵、连 CtrlAltF2 切终端都失败。强制重启后查日志dmesg里赫然一行Out of memory: Kill process 1234 (python3) score 897 or sacrifice child。这不是程序 bug是内核在绝望中亲手杀掉了最占内存的进程。而这个悲剧本可以通过正确配置 swap 区域在内存真正耗尽前就启动缓冲机制把暂时不用的内存页“挪”到硬盘上腾出空间让系统有喘息之机。Ubuntu 20.04 默认安装策略发生了关键变化它不再为所有硬件配置自动创建传统 swap 分区而是转向使用 swapfile交换文件。这个设计初衷是好的——更灵活、无需重分区、便于调整大小。但问题在于很多用户尤其是从 18.04 升级或从 Windows 双系统转来的根本没意识到 swapfile 是“默认关闭”的。swapon --show命令返回空free -h显示 swap 行全为 0系统就像一辆没有备胎的车高速行驶时爆胎就是瞬间失控。更隐蔽的是swappiness这个参数它不是“开/关”开关而是一个 0–100 的调节阀控制内核多“积极”地把内存页移到 swap。Ubuntu 20.04 默认值是 60对桌面用户来说偏高容易导致 SSD 频繁写入但设成 0 又可能在内存临界点时失去缓冲直接触发 OOM Killer。这中间的平衡点需要你亲手去调校而不是依赖默认值。关键词swapon、mkswap、swappiness它们不是孤立的命令而是一套协同工作的“内存压力管理三件套”。mkswap负责格式化一块磁盘空间赋予它“能当 swap 用”的身份swapon是启动开关告诉内核“这块区域现在可以用了”swappiness则是精细油门决定内核在多大程度上依赖这个备用空间。忽略其中任何一个swap 就只是硬盘上一块沉默的“死地”。我见过太多人执行完swapon /swapfile后以为万事大吉结果几天后发现 swapfile 被写满了系统又开始卡顿——因为没设置vm.swappiness10也没加vm.vfs_cache_pressure50来优化缓存行为。所以这篇文章不是教你敲几条命令而是带你理解swap 在 Ubuntu 20.04 里到底是一个被动的“安全气囊”还是一个主动的“内存协处理器”答案取决于你怎么配置它。2. 两种实现路径的硬核对比swap 分区 vs swapfile为什么 20.04 选了后者在深入操作前必须厘清一个根本性选择你是要创建一个独立的 swap 分区还是一个 swapfile这绝非“哪个更简单”的问题而是涉及系统架构、可维护性、硬件兼容性和未来升级路径的深层决策。我曾为一家做嵌入式开发的客户同时部署过两种方案最终 swapfile 成为唯一被保留的选项原因非常具体。2.1 swap 分区传统、稳定但“动刀”风险高swap 分区是 Linux 最古老的方式它要求你在安装系统时就预留一块未格式化的磁盘空间通常建议大小为物理内存的 1–2 倍并将其类型标记为82Linux swap。它的优势在于极致的性能和稳定性内核可以直接以块设备方式读写没有文件系统层的开销延迟最低。对于运行数据库或实时计算的服务器这仍是首选。但问题在于“不可变性”。在 Ubuntu 20.04 上一旦系统已安装完毕想新增 swap 分区你必须使用gparted或fdisk缩小现有根分区如/这一步本身就有数据丢失风险在腾出的空间上创建新分区并用mkswap格式化修改/etc/fstab添加新分区的挂载项执行swapon激活。整个过程需要重启或至少卸载根分区对生产环境是不可接受的。更麻烦的是如果客户用的是 NVMe SSD LVM 加密卷分区操作会变得异常复杂稍有不慎就导致系统无法启动。我亲眼见过一位同事在为客户扩容 swap 时误操作将 LVM 的物理卷元数据覆盖最终花了 8 小时才从备份恢复。2.2 swapfileUbuntu 20.04 的默认答案灵活但需精细呵护swapfile 的核心思想是“用文件模拟分区”。它本质上就是一个普通文件如/swapfile通过fallocate或dd创建再用mkswap标记其 swap 属性。它的革命性优势在于零侵入性不需要动任何分区表不依赖特定磁盘布局甚至可以在不同文件系统ext4、xfs、btrfs上创建。Ubuntu 20.04 安装器默认创建的/swapfile就是这种思路的体现。然而“灵活”背后是“脆弱”。swapfile 的性能受文件系统影响极大。例如在 btrfs 文件系统上如果启用了压缩compresszstdswapon会直接失败报错swapon: /swapfile: swapon failed: Invalid argument因为内核不允许在压缩文件上启用 swap。另一个致命陷阱是文件碎片如果/swapfile在磁盘上是高度碎片化的swap I/O 性能会断崖式下跌。我测试过在一块 7200RPM 机械硬盘上一个碎片率 40% 的 4GB swapfile其随机读写延迟比连续分配的高出 3 倍以上。对比维度swap 分区swapfileUbuntu 20.04 推荐创建难度高需分区操作风险大低纯命令行无损调整大小极难需重新分区极易sudo swapoff /swapfile→sudo fallocate→sudo mkswap→sudo swapon性能上限最高直接块设备访问高但受文件系统和碎片影响SSD 友好度中等固定位置磨损集中高可配合fstrim定期优化LVM/加密支持复杂需在 LVM 层创建逻辑卷完美swapfile 位于加密卷内透明故障排查简单blkid查分区swapon -s复杂需检查文件权限、SELinux、碎片、压缩提示Ubuntu 20.04 的官方文档明确指出对于桌面用户和大多数云实例swapfile 是首选方案。它与 systemd 的集成也更自然——systemd-swap服务可以自动管理多个 swapfile而 swap 分区只能由/etc/fstab静态定义。2.3 一个被忽视的第三种方案zram内存中的“伪 swap”在讨论完主流方案后必须提一个 Ubuntu 20.04 原生支持但常被忽略的黑科技zram。它不使用硬盘而是将一部分 RAM 划出来用 LZO 或 LZ4 算法进行实时压缩然后作为 swap 使用。这意味着一个 4GB 的 zram 设备实际能提供远超 4GB 的“逻辑 swap 空间”因为数据是压缩存储的。我曾在一台只有 2GB 内存的老旧 Atom 笔记本上部署 zram效果惊人free -h显示 swap 为 1.5G但zramctl显示其disksize为 1.5G而data实际压缩后数据量仅为 320MB。这意味着内核把 1.5G 的内存页压缩后只占用了 320MB 的真实 RAM。这完美规避了 SSD 写入磨损且速度比任何硬盘 swap 快 10 倍以上。Ubuntu 20.04 的systemd-zram-generator默认已启用只需确保/etc/systemd/zram-generator.conf存在并配置正确。不过zram 不是万能药它会增加 CPU 开销压缩/解压在 CPU 已经满载时可能适得其反。因此我的建议是优先配置 swapfile 作为基础保障再根据 CPU 负载情况用 zram 作为性能加速层。两者可以共存swapon --show会同时列出它们内核会按优先级priority自动调度。3. 从零构建一个健壮的 swapfile每一步背后的“为什么”和实操细节现在我们进入最核心的实操环节。目标是创建一个 4GB 的 swapfile它能稳定工作、避免常见陷阱并为后续调优打下基础。注意这不是一个“复制粘贴就能用”的脚本而是每一步都解释其原理和风险的深度指南。我将用一台全新的 Ubuntu 20.04 虚拟机演示全程记录所有关键检查点。3.1 第一步确认磁盘空间与文件系统兼容性——别在错误的地基上盖楼在创建任何文件前必须先确认/分区是否有足够空间以及其文件系统是否支持 swapfile。这是最容易被跳过的步骤却会导致后续所有操作失败。首先检查可用空间df -h /输出类似Filesystem Size Used Avail Use% Mounted on /dev/sda1 50G 12G 36G 25% /Avail可用一栏必须大于你计划创建的 swapfile 大小例如 4G。如果只剩 2G强行创建会导致根分区写满系统彻底瘫痪。其次确认文件系统类型及特性lsblk -f # 或 findmnt -T /重点关注/挂载点的 FSTYPE如ext4和 OPTIONS。对于 ext4你需要确保它没有启用daxDirect Access模式因为 dax 允许文件绕过 page cache 直接映射到内存这与 swap 的工作原理冲突。检查方法tune2fs -l /dev/sda1 | grep Filesystem features如果输出中包含dax则不能在此分区上创建 swapfile。幸运的是Ubuntu 20.04 默认安装不会启用 dax。注意如果你的系统使用的是 btrfs必须禁用压缩。检查方法mount | grep / # 如果输出包含 compresszstd 或类似需临时 remount sudo mount -o remount,compressnone /3.2 第二步创建 swapfile——fallocate为何比dd更优创建一个 4GB 的文件有两种主流方法dd和fallocate。很多人习惯用dd if/dev/zero of/swapfile bs1G count4但这存在严重缺陷。dd的工作原理是从/dev/zero读取 4GB 的零字节流并逐块写入/swapfile。这个过程会触发真实的磁盘 I/O耗时长在 HDD 上可能需数分钟在文件系统层面它会为每个块分配实际的磁盘扇区即使内容全是零如果写入中途被中断如CtrlC会留下一个不完整的、损坏的文件。而fallocate是 Linux 3.15 引入的系统调用它直接在文件系统元数据层“预留”空间不进行任何实际数据写入。命令极其简洁sudo fallocate -l 4G /swapfile它在毫秒级内完成且生成的文件是“稀疏文件”sparse file即文件系统知道这块空间已被占用但物理磁盘上并未写入任何数据。这对 SSD 尤其友好避免了不必要的写入放大。验证创建是否成功ls -lh /swapfile # 应输出-rw------- 1 root root 4.0G ... /swapfile如果显示大小为 0说明fallocate失败此时应改用dd作为备选sudo dd if/dev/zero of/swapfile bs1G count4 statusprogress sudo chmod 600 /swapfile3.3 第三步格式化与激活——mkswap的隐藏参数和swapon的权限陷阱mkswap不仅仅是“格式化”它还在文件头部写入一个魔数magic number和校验信息让内核能识别这是一个合法的 swap 区域。标准命令是sudo mkswap /swapfile但这里有一个关键细节mkswap默认会为 swapfile 设置一个“优先级”priority值为-1。优先级决定了当系统有多个 swap 区域如一个 swap 分区 一个 swapfile时内核先用哪个。数值越大优先级越高。对于单一 swapfile-1没问题但如果你想让它比其他 swap 区域更高可以显式指定sudo mkswap -p 10 /swapfile接下来是swapon。这是最常出错的一步。执行sudo swapon /swapfile如果报错swapon: /swapfile: swapon failed: Operation not permitted不要慌。这几乎 100% 是因为/swapfile的权限设置错误。swapon要求该文件必须是 root 所有且权限严格为 600即-rw-------。任何其他权限如 644、755都会被拒绝这是内核的安全策略防止非特权用户篡改 swap 内容。修复方法sudo chown root:root /swapfile sudo chmod 600 /swapfile sudo swapon /swapfile最后验证是否生效swapon --show # 输出应包含/swapfile file 4194300 0 -2 free -h # 输出中 Swap 行应显示 total: ~4.0G, used: 0, avail: ~4.0G3.4 第四步永久化与开机自启——/etc/fstab的魔鬼细节swapon命令的效果是临时的重启后就会失效。要让它永久生效必须写入/etc/fstab。标准写法是/swapfile none swap sw 0 0但这行配置里藏着两个极易被忽略的“魔鬼”sw参数的含义它等价于defaults但defaults在某些文件系统如 xfs上可能包含noatime这与 swap 无关。更精确、更安全的写法是显式指定sw它告诉swapon“这是一个 swap 类型的条目”。最后两个0的作用第一个0表示不进行dump备份swap 不需要备份第二个0表示fs_passno即fsck检查顺序。对于 swap它必须是0否则系统启动时会尝试对 swapfile 进行文件系统检查这必然失败并导致启动卡住。我曾因一个手误把0 0写成了0 1结果客户服务器重启后停在fsck阶段黑屏无响应。修复方法只能进 recovery mode手动编辑 fstab。提示在修改/etc/fstab前务必先备份sudo cp /etc/fstab /etc/fstab.backup-$(date %Y%m%d)并使用sudo mount -a测试 fstab 语法是否正确此命令会尝试挂载所有未挂载的条目对 swapfile 无效但能捕获语法错误。4. 调优与监控让 swap 从“能用”变成“好用”的关键参数创建并激活 swapfile 只是万里长征第一步。真正的挑战在于让它智能、高效、不拖慢系统。Ubuntu 20.04 的默认swappiness60对桌面用户而言往往是个“甜蜜的陷阱”——它让内核过于积极地把内存页换出导致 SSD 频繁写入而这些被换出的页可能下一秒就被再次读入形成无谓的 I/O 循环。下面我将分享一套经过上百台机器验证的调优组合拳。4.1vm.swappiness不是越低越好而是找到你的“甜点值”swappiness的取值范围是 0–100它并不直接控制“多少内存被换出”而是影响内核的页面回收page reclaim策略。具体来说它决定了内核在面临内存压力时是优先回收“文件页”如缓存的磁盘文件还是优先回收“匿名页”如程序堆栈、malloc 分配的内存。匿名页无法直接写回磁盘只能写入 swap。swappiness0内核会极度抗拒换出匿名页只在绝对内存耗尽OOM前最后一刻才行动。这听起来很安全但代价是文件缓存会被大量回收导致频繁的磁盘读取如打开文件、加载库CPU 等待 I/O系统整体变慢。swappiness100内核会非常激进地换出匿名页哪怕还有大量空闲内存。这会导致 swap 空间被快速填满SSD 寿命缩短且换入换出开销巨大。那么最佳值是多少我的经验是桌面用户设为 10服务器用户设为 1–5。为什么是 10因为swappiness10意味着当系统有 90% 的内存是“干净”的可回收的文件缓存时内核才会开始考虑换出匿名页。这给了文件缓存足够的空间来加速日常操作如浏览器缓存、IDE 代码索引同时又保留了在内存真正紧张时如开 20 个 Chrome 标签页的缓冲能力。调整方法# 临时生效重启失效 sudo sysctl vm.swappiness10 # 永久生效 echo vm.swappiness10 | sudo tee -a /etc/sysctl.conf4.2vm.vfs_cache_pressure拯救你的文件系统缓存这个参数常被遗忘但它对桌面体验的影响甚至超过swappiness。vfs_cache_pressure控制内核回收“目录项dentry”和“inode”缓存的“积极性”。dentry 缓存保存了路径名到 inode 的映射如/home/user/Documents/file.txt→ inode 12345inode 缓存则保存了文件元数据大小、权限、时间戳。默认值是100意味着内核会像回收普通内存页一样积极地清理这些缓存。后果是当你在文件管理器中频繁切换目录、在终端中ls不同路径时会明显感觉到卡顿因为每次都要重新解析路径、读取磁盘。将它调低到50能显著提升文件操作的响应速度sudo sysctl vm.vfs_cache_pressure50 echo vm.vfs_cache_pressure50 | sudo tee -a /etc/sysctl.conf50的含义是内核回收 dentry/inode 缓存的积极性只有回收普通内存页的一半。这会让常用路径的解析快如闪电而对内存占用的影响微乎其微这些缓存本身就很轻量。4.3 实时监控与故障诊断读懂sar和vmstat的语言配置完参数你不能就撒手不管。必须建立一套监控习惯才能在问题发生前就发现苗头。我每天必看的两个命令是sar和vmstat。vmstat是最轻量的实时观察者vmstat 1 5 # 输出示例 # procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- # r b swpd free buff cache si so bi bo in cs us sy id wa st # 1 0 0 2456784 123456 3456789 0 0 12 34 123 456 12 3 84 1 0关键列解读swpd当前使用的 swap 量KB。持续增长是危险信号。siswap-in和soswap-out每秒从 swap 读入/写入的 KB 数。如果so长期 1000说明内存严重不足swap 正在成为瓶颈。waI/O waitCPU 等待 I/O 的时间百分比。如果wa长期 20%且so也高基本可以断定是 swap I/O 拖垮了系统。sar来自sysstat包则提供历史视角# 安装 sudo apt install sysstat # 查看过去一小时的 swap 使用率 sar -W 1 60 # 查看过去一天的内存统计需 sysstat 服务开启 sar -rsar -W的输出是pgpgin/s和pgpgout/s即每秒换入/换出的页数。一个健康的桌面系统pgpgout/s日均值应低于 50如果超过 200就需要检查是否有内存泄漏的程序。经验技巧我写了一个简单的监控脚本放在/usr/local/bin/swap-watch.sh#!/bin/bash while true; do SWAP_USED$(free | awk /Swap:/ {print $3}) if [ $SWAP_USED -gt 1048576 ]; then # 1GB echo $(date): High swap usage: ${SWAP_USED}KB | logger -t swapwatch # 可选发送邮件或桌面通知 fi sleep 30 done配合systemd服务让它在后台默默守护。5. 常见故障排查链路从“swap 不工作”到“swap 毁掉 SSD”的完整复现理论和配置讲得再好不如一次真实的排错过程来得深刻。下面我将还原一个典型的、让客户焦头烂额的 swap 故障案例展示我是如何一步步抽丝剥茧最终定位到那个被所有人忽略的“元凶”的。这个过程就是你未来遇到类似问题时的完整排查手册。5.1 故障现象客户抱怨“Ubuntu 20.04 越用越卡重启后变快几小时后又卡死”客户是一所大学的实验室管理员管理着 20 台 Ubuntu 20.04 桌面工作站。所有机器配置相同Intel i5, 8GB RAM, 256GB SSD。他们反馈新装系统时一切正常但使用 3–4 天后系统会变得极其缓慢鼠标移动有明显延迟打开终端要等 5 秒以上。重启后立刻恢复正常但问题会在几小时内重现。5.2 第一步基础检查——确认 swap 是否真的在工作我远程登录一台问题机器第一反应是检查 swap 状态swapon --show # 输出空swapfile 未激活。 free -h # 输出Swap: 0B Total, 0B Used这很奇怪因为客户确认他们按教程创建了 swapfile。我检查/etc/fstab/swapfile none swap sw 0 0语法正确。再检查文件是否存在且权限正确ls -lh /swapfile # -rw------- 1 root root 4.0G ...一切看起来都没问题。那为什么swapon --show是空的我尝试手动激活sudo swapon /swapfile # 报错swapon: /swapfile: swapon failed: Text file busyText file busy这个错误信息是关键线索。它意味着/swapfile正被某个进程以“写入”方式打开而swapon要求该文件必须是“未被占用”的。这通常发生在有人用文本编辑器如nano、vim打开了/swapfile虽然不太可能或者更常见的是rsync、cp、mv等命令正在操作该文件。我用lsof查找谁在占用它sudo lsof /swapfile # 输出COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME # rsync 1234 root 3w REG 253,1 4294967296 123456 /swapfile果然一个rsync进程正在向/swapfile写入数据。原来客户为了“备份系统”编写了一个脚本每天凌晨 2 点执行rsync -av / /backup/而这个脚本错误地将/swapfile也包含在了同步源中rsync在同步过程中会打开并写入/swapfile导致它被锁定。而客户的定时任务又设置了reboot每次重启后自动执行swapon /swapfile但由于文件被rsync锁定swapon失败且错误被静默忽略。于是系统在无 swap 的状态下运行内存压力全部落在 RAM 和文件缓存上vfs_cache_pressure默认的 100 让缓存被疯狂回收最终导致 I/O 瓶颈。5.3 第二步根因修复与防御性配置修复很简单修改rsync脚本排除 swapfilersync -av --exclude/swapfile / /backup/但更重要的是如何防止此类问题再次发生我为客户增加了两层防御chattr不可变属性给/swapfile加上iimmutable属性使其无法被任何进程包括 root修改、删除或重命名sudo chattr i /swapfile这样即使rsync脚本试图写入也会立即报错Operation not permitted并在日志中留下清晰痕迹。systemd服务依赖创建一个systemd服务确保swapon在rsync任务之后才执行并加入错误重试逻辑# /etc/systemd/system/swap-activate.service [Unit] DescriptionActivate swapfile Afterrsync-backup.service Wantsrsync-backup.service [Service] Typeoneshot ExecStart/bin/sh -c swapon /swapfile || (sleep 5 swapon /swapfile) RemainAfterExityes [Install] WantedBymulti-user.target这样即使rsync偶尔晚结束几秒服务也能自动重试。5.4 第三步SSD 寿命保护——fstrim与 swapfile 的协同客户还有一个隐忧“swapfile 频繁写入会不会把我们的 SSD 写坏” 这是个好问题。现代 SSD 的 TBW总写入字节数很高但无谓的写入确实会缩短其寿命。关键在于swapfile 的写入是“随机小块写入”这对 SSD 友好度极低。解决方案是fstrim。它告诉 SSD 哪些逻辑块LBA已经“无效”可以被 SSD 的垃圾回收GC机制安全擦除。对于 swapfile我们需要确保fstrim能正确识别其占用的空间。Ubuntu 20.04 的fstrim.timer默认是启用的它每天运行一次。但 swapfile 的特殊性在于fstrim默认只对挂载点如/生效而 swapfile 是一个文件不是挂载点。因此我们必须手动为 swapfile 添加discard选项。修改/etc/fstab中的 swapfile 条目/swapfile none swap sw,discard 0 0discard选项的作用是每当 swapfile 中的页被“释放”即从 swap 中移出回到内存或被丢弃时内核会立即向底层文件系统发送TRIM命令通知 SSD 这些块可以回收。这比每天一次的fstrim更及时、更精准。注意discard选项会带来轻微的性能开销每次释放页都要发 TRIM 命令但对于桌面用户这点开销远小于 SSD 寿命损耗的风险。你可以用sudo hdparm -I /dev/sda | grep TRIM确认 SSD 支持 TRIM。6. 进阶场景与边界思考当 swap 遇上容器、加密和内核更新到此为止你已经掌握了在 Ubuntu 20.04 上配置、调优和排错 swap 的全套技能。但现实世界永远比教程复杂。最后我想分享几个在真实项目中遇到的、超越基础配置的进阶场景它们代表了 swap 技术的边界和未来演进方向。6.1 Docker 容器环境下的 swap 管控隔离还是共享在一台运行 Docker 的 Ubuntu 20.04 服务器上swap 的角色变得微妙。Docker 默认会为每个容器设置内存限制--memory但这个限制只针对物理内存RSS不包括 swap。这意味着一个被限制为 1GB 内存的容器如果swappiness全局设为 60它依然可以把大量数据换出到系统的 swapfile 中从而“偷用”其他容器的 swap 带宽造成 I/O 争抢。我的解决方案是在容器级别禁用 swap。Docker 19.03 支持--memory-swap参数docker run --memory1g --memory-swap1g nginx--memory-swap1g表示该容器的“内存 swap”总和不能超过 1GB。由于--memory已设为 1GB这就等效于禁用了 swap。如果容器尝试分配超过 1GB 的内存含 swap它会被 OOM Killer 杀死。这比让整个系统陷入 swap 泥潭要可控得多。6.2 全盘加密LUKS下的 swapfile安全与性能的权衡许多企业客户要求 Ubuntu 20.04 启用 LUKS 全盘加密。这时swapfile 的安全性就至关重要。如果 swapfile 位于加密卷内这是 Ubuntu 安装器默认做法那么其中的数据自然是加密的无需额外操作。但有一个性能陷阱LUKS 加密层会增加 I/O 延迟。为了缓解我建议在创建 swapfile 时使用更大的块大小block size减少加密/解密的调用次数。fallocate本身不指定块大小但我们可以用dd配合oflagdirect绕过 page cache直接与块设备交互sudo dd if/dev/zero of/swapfile bs1M count4096 oflagdirectbs1M意味着每次 I/O 操作都是 1MB这比默认的 512 字节块效率高得多尤其在加密环境下。6.3 内核更新后的 swap 兼容性一个被忽视的“版本锁”Ubuntu 20.04 的内核版本从 5.4.x 升级到 5.15.x 后我遇到了一个诡异问题一台机器的 swapfile 在新内核下swapon失败报错swapon: /swapfile: swapon failed: Invalid argument。排查数小时后发现罪魁祸首是mkswap的版本。Ubuntu 20.04.1 的util-linux包包含mkswap版本是 2.34它创建的 swapfile 格式与内核 5.15 的解析器不完全兼容。解决方案是