Linux mkswap命令详解：swap分区与swap文件的完整实践指南

最近在维护一批线上服务器的时候，又碰到磁盘空间报警，顺手处理完swap分区之后，突然想到这个系列已经写到第008篇了，正好借着这个契机，把mkswap命令单独拎出来好好聊一聊。说实话，日常运维里swap这块用得不算频繁，但只要涉及新机器初始化、老机器扩内存、或者磁盘整列迁移，mkswap就是绕不开的那道坎。

这篇主要面向刚入行的运维新手、自学Linux的开发者，以及那些想系统性补一补Linux命令基础的读者。我会从swap的基本概念讲起，到mkswap的参数细节、实操步骤、开机自动挂载，再到我这些年踩过的坑，一步一步拆给大家看。保证你看完不只是会敲一条命令，而是能理解背后的原理，真正能在生产环境里放心使用。

1. 先用大白话把swap讲清楚

很多朋友学Linux命令喜欢死记硬背，但命令这东西，不理解场景就记不牢，理解了场景一辈子忘不掉。mkswap这个命令，核心作用就一句话：把一块磁盘分区或者一个文件，格式化成可以当内存交换空间使用的形态。这就像你买了一个空房间，mkswap相当于把它做了精装修，让它能住人——这里“住的人”就是暂时无处安放的内存数据。

1.1 为什么Linux需要swap空间

先聊个基础但关键的问题：Linux为什么需要swap？内存不够用的时候，操作系统会挑出一些暂时不用的内存数据，写到磁盘上保存起来，把物理内存腾出来给正在运行的程序用。这个过程叫换出（swap out），等程序需要这些数据了，再把它读回来，叫换入（swap in）。磁盘在这里扮演的角色，就是内存的“临时仓库”。

换出和换入虽然是无奈之举，但如果没有这层缓冲，内存一旦占满，系统会直接触发OOM（Out Of Memory）机制，随机挑选进程杀掉。那种体验，经历过的人都知道，SSH连不上、服务突然挂掉、日志刷出一堆oom-killer，比你女朋友无缘无故发脾气还让人头大。

所以，swap空间的核心价值不是让系统跑得更快，而是让系统在内存吃紧的时候，还能保持基本可用，给运维人员留出排查和扩容的时间。网上有人鼓吹“内存够大就不需要swap”，我个人不太赞同。哪怕你的机器有256G内存，留一小块swap做个兜底，在应对突发内存尖峰时，心里会踏实很多。

Linux的swap空间有两种载体：一种是独立的磁盘分区，叫swap分区；另一种是普通文件，叫swap文件。mkswap命令对这两种载体都适用，这也正是它灵活的地方。后面我会分开讲这两种方式的创建流程和适用场景。

1.2 swap空间从哪来、怎么进系统

swap空间要真正被系统使用，需要经过几个步骤。第一步，你得有一块磁盘分区或一个文件作为载体；第二步，用mkswap命令把这个载体“格式化”成swap的格式，往里面写入必要的元数据信息；第三步，用swapon命令激活它，让内核正式把这部分空间纳入内存管理；第四步，如果需要开机自动生效，还要把挂载信息写进配置文件。

这里面，mkswap就像是“装修队”，它干的是最核心也是最容易被忽略的活。很多人以为mkswap只是写几个标记位，没什么技术含量，实际上它还要完成坏块检查、页大小对齐等一系列底层的初始化工作。参数选不对，后续使用swap时会莫名其妙出现性能问题，甚至系统启动时报错。

还有一点值得注意：swap空间不是无限使用的。当系统内存充足时，swap完全是空转的，不占CPU也不占内存，只占一点点磁盘空间而已。所以完全不用担心“开了swap会不会拖慢系统”这种问题，只要你不把swappiness参数调得过于激进，swap在正常负载下基本是沉睡状态。

1.3 什么时候才需要碰mkswap

简单汇总一下我实际工作中会用到mkswap的场景，大家可以对号入座：

• 新服务器装机，磁盘阵列配置完成后，需要划分一块区域做swap分区。
• 原有swap分区所在磁盘故障，需要更换磁盘并重新创建swap。
• 物理内存扩容后，希望同步扩大swap空间，这时可能要新建更大的swap分区。
• 磁盘分区方案变更，比如从MBR切换到GPT，原有的swap分区必须重建。
• 云服务器数据盘重新挂载、初始化时，顺手把swap也重置一遍。
• 用swap文件替代swap分区，做临时性的内存扩充。

在这些场景里，mkswap都是那条关键的“格式化”命令。理解它、用好它，你的Linux运维基本功就算又扎实了一层。

2. 创建swap前，先把这些准备工作做扎实

回到实操上。很多新手喜欢直接敲命令，敲错了再慢慢改。我建议还是先花两分钟把准备工作做做齐，尤其是在生产环境里，一个不小心就是事故现场。

2.1 分区还是文件：两条路线怎么选

先解决一个纠结的问题：创建swap的时候，到底用独立分区，还是用swap文件？

我的建议是，生产环境优先用独立分区。因为swap分区的数据写入是块设备级别的，不经过文件系统那一层，读写效率更高；而且独立分区不容易被误删，也不容易因为文件系统碎片化而性能劣化。缺点是需要提前规划分区方案，灵活性差一些。

swap文件则胜在灵活。任何时候，只要磁盘有空闲空间，你都可以用dd命令创建一个大文件当swap用，不需要重新分区，也不用停机。缺点是需要经过文件系统层，性能略低于独立分区；而且文件系统如果出问题，swap文件也可能会受牵连。

这里举个例子：我在AWS云服务器上创建swap时，因为云盘是整块数据盘，不想破坏原有分区结构，就直接在数据盘上创建了一个swap文件，操作又快又安全。但在物理服务器的装机阶段，我一般会通过fdisk分出一个专门的swap分区，避免后续扩容、迁移时分不清空间归属。

另外提醒一句：千万不要在系统盘上创建swap文件，除非你确认系统盘的剩余空间足够大。系统盘写入频繁会影响系统稳定性，而且系统盘空间耗尽时，swap文件也起不到兜底作用，反而会让系统雪上加霜。

2.2 swap大小怎么定：不是越长越好

swap文件或swap分区多大合适？网上各种说法都有，有的说等于物理内存的2倍，有的说8G封顶。我的经验是，没有一个绝对的数字，得看实际用途。

对于桌面Linux或者开发机，物理内存够用的情况下，swap设个2-4G就足够了，主要起兜底作用。对于服务器，特别是跑数据库、缓存服务的内存密集型的机器，swap的大小需要根据业务特征来定。如果业务负载稳定，内存峰值可控，swap设小一些甚至关掉都没关系；如果业务有突发性，比如秒杀活动、大数据计算，swap建议设置成物理内存的0.5到1倍，留出缓冲空间。

有一种情况要特别注意：如果物理内存只有1G或2G的小机器，跑着Java应用或者编译大型软件时，swap不足会直接导致构建失败。这种场景我建议直接把swap设置成物理内存的2倍以上，甚至更大。说白了，swap大小要充分考虑业务模型，不是拍脑袋定出来的。

还有个细节：swap分区的逻辑卷（LVM）化管理。如果你用的是LVM，后续调整swap大小非常方便，可以先lvreduce或lvextend，再重新执行mkswap和swapon，不需要动物理分区。这也是我推荐在条件允许的情况下用LVM管理swap的原因。

2.3 工具链准备与环境检查

动手前，先用命令确认环境和目标设备，别稀里糊涂就敲mkswap。我自己常用的检查命令就这几条：

bash复制# 查看当前系统内存和swap使用情况
free -h

# 查看磁盘分区情况
fdisk -l

# 查看块设备UUID和挂载状态
blkid

# 查看当前swap设备列表
swapon --show

这几条命令跑一遍，你对系统当前的状态就心里有数了。尤其是blkid，它显示的UUID值非常关键。生产环境中，/etc/fstab里挂载swap通常会用UUID而不是设备名，因为设备名在重启后有变化的可能，UUID则保持稳定。

另外，创建swap文件前一定要确认目标分区有没有足够的剩余空间：

bash复制df -h

这里插一个我踩过的坑：曾经在一个只有10G剩余空间的数据盘上创建8G的swap文件，结果dd执行到一半磁盘满了，系统直接进入只读模式，最后折腾了好久才恢复。后来我就养成了一个习惯，swap文件的最终占用大小和临时占用的缓冲都提前算进去，宁可保守一点，也不冒进。

还有一个前置条件：如果你创建swap的载体是磁盘分区，确保这个分区已经被标记为swap类型（分区类型代码是82，Linux swap / Solaris）。用fdisk进入交互界面，查看分区的System列，如果不是Linux swap / Solaris，用t指令改过来。这个类型标记虽然不影响mkswap写入数据，但在一些工具和界面中会有提示作用，规范操作还是别省这一步。

3. mkswap核心实操：语法、参数、上机

准备工作做完了，进入正题。mkswap命令的语法本身不复杂，但每一条参数都有它存在的意义。把参数吃透，你在实战中遇到各种需求时，才能有的放矢。

3.1 mkswap命令解析与关键参数

mkswap的完整语法如下：

bash复制mkswap [参数] [设备或文件名] [块数]

常用参数我来逐个说明：

-c：格式化前先做一次坏块检查。这个参数在设备上执行时，mkswap会先读取整个设备，标记并跳过坏块。虽然会花一点时间，但对磁盘品质没把握的情况下，强烈建议加上。如果在检查过程中发现坏块，mkswap会根据坏块表自动保留相应区域，有效避免后续使用时的数据损坏。

-f：强制格式化。有时候mkswap会嫌你给它的设备已经存在文件系统或分区表，拒绝执行。例如对整块磁盘执行mkswap时（不是对分区），因为磁盘上可能残留了GPT或MBR引导数据，mkswap会提示"Device is busy"或"already contains a filesystem"。这时候加上-f参数可以强制覆盖写入。但慎用，尤其要确认自己没选错设备。

-L label：给swap空间打一个标签，比如-L swap1。这个标签会写入swap的超级块中。有了标签，后续可以用swapon /dev/disk/by-label/swap1或标签引用来激活swap，在有多块swap设备的场景下，这个功能非常有用，可以避免搞混设备。

-U uuid：手动指定swap分区的UUID。正常情况下mkswap会自动生成UUID，但如果你在脚本或自动化工具里有固化UUID的需求，就可以用这个参数指定。比如迁移数据时想把新swap设备的UUID配成和旧设备一致，减少配置文件改动。

-p pagesize：指定页大小。这个参数一般在嵌入式设备或特殊架构上使用。绝大多数x86_64服务器用默认值就行，不用额外操心。

-v：显示详细执行信息。

-v（小写v）在某些版本中是交换空间版本选择，而-E是另一个常用于做坏块处理的参数。不同发行版的mkswap来自不同的util-linux版本，参数细节略有差别。使用前最好man一下，以本机帮助文档为准。

还有个容易忽略的知识点：mkswap在格式化前，需要确保交换设备上没有打开的文件句柄或挂载点，否则会提示设备忙。这也是为什么swap分区一旦挂载过、正在使用中，必须先用swapoff停掉，才能重新mkswap。

3.2 场景一：全新分区做swap

这是最标准的流程，适合新装机或全新磁盘。假设我们有一块新加的磁盘/dev/sdb，想在它上面创建一个swap分区，整个步骤如下。

先用fdisk创建分区并标记类型：

bash复制# 交互式进入fdisk，操作对象是 /dev/sdb
fdisk /dev/sdb

# 进入fdisk交互界面后，依次输入：
# n -> p -> 回车（默认分区号）-> 回车（默认起始扇区）-> +4G（分区大小，按需调整）
# t -> 82（分区类型改为 Linux swap / Solaris）
# w（保存退出）

分区创建好后，系统会生成/dev/sdb1，接下来用mkswap初始化它：

bash复制mkswap -c -L swap1 /dev/sdb1

如果一切顺利，输出大概长这样：

bash复制Setting up swapspace version 1, size = 4 GiB (4294963200 bytes)
no label, UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

这就代表swap分区已经初始化完成。这里我加了个-c参数做坏块检查，第一次使用新磁盘时，这个检查非常有必要，能提前暴露磁盘质量问题。

然后激活并确认：

bash复制swapon /dev/sdb1
swapon --show

至此，一个新的swap分区就创建成功了。但这个状态只是临时的，重启后不会自动挂载，需要配置/etc/fstab把它固化下来，这一步我在第4节单独讲。

可能有人会问：如果磁盘上已经存在分区表，mkswap之后会不会影响其他分区？答案是：一般不会。mkswap只对目标分区写入数据，只要你的目标分区指定正确，不会碰其他分区。但如果因为手误指定了整块磁盘，比如把/dev/sdb当成/dev/sdb1，那后果就很严重了——整块磁盘会被覆盖成swap格式，所有数据全没。所以每次执行mkswap之前，我都会用pwd和lsblk再三确认设备名。

3.3 场景二：swap文件替代分区

有些场景下，不适合重新划分磁盘分区，比如云服务器的数据盘已经格式化好了、或者系统是预装镜像不方便动分区表。这时的最佳方案就是swap文件。创建swap文件的核心命令还是mkswap，但之前多了一个制造文件的过程。

我推荐用fallocate来创建swap文件，它比dd更快，因为它不实际写入数据，只分配磁盘空间。但要注意，对swap文件，fallocate创建的文件可能因底层文件系统的原因存在“空洞”，导致mkswap不能正常处理。我自己实测中，ext4和xfs都没有遇到问题，但如果用某些网络文件系统，还是建议用dd更稳妥。保守做法是直接用dd：

bash复制# 在 /data 下创建 4G 的 swapfile
dd if=/dev/zero of=/data/swapfile bs=1M count=4096

# 调整权限，只允许root读写，避免普通用户读到内存交换内容导致信息泄露
chmod 600 /data/swapfile

# 格式化为swap文件
mkswap /data/swapfile

# 启用
swapon /data/swapfile

有两点必须提醒：第一，swap文件一定要用绝对路径，后续配置fstab和swapon时都要保持一致；第二，权限必须是600。如果你用默认权限644创建swap文件，swapon时系统会给出"insecure permissions"警告，虽然还能用，但这是个安全隐患。因为swap文件里存放的是内存中的敏感数据，任何用户都能读的话，系统密码、密钥就可能泄露。

还有一个细节：swap文件所在文件系统，如果开启了写时复制（如Btrfs），创建swap文件前需要关闭相关属性，否则swapon会报错Invalid argument。Btrfs用户执行这句：

bash复制chattr +C /data/swapfile

另外，swap文件不建议放在系统根目录，因为根目录空间通常紧张，一旦文件系统满了，可能出现连锁问题。放独立数据盘是最优选择。

3.4 场景三：更换旧磁盘时的swap重建

在生产环境里，swap最头疼的不是创建，而是旧盘退役时swap跟着一起没了。这里分享一个我实际操作的案例。

当时有一台机器，swap分区建在一块老旧的机械盘上，那块盘已经出现了坏道。我的方案是：先用一块新盘建好新的swap分区，再让系统切换到新swap，最后才把旧盘下线。顺序千万别搞反，否则中途内存不够用，系统可能直接卡死。

操作顺序如下：

先在备用新盘上创建新的swap分区：

bash复制fdisk /dev/sdc
# n -> p -> 默认分区号 -> 默认起始扇区 -> +4G -> t -> 82 -> w
mkswap /dev/sdc1
swapon /dev/sdc1

然后关闭旧swap：

bash复制swapoff /dev/sdb2

确认新swap生效：

bash复制swapon --show
free -h

最后把/etc/fstab里的旧UUID更新为新UUID，去掉旧盘的所有挂载项，才能安全拔盘。这里再强调一遍：在生产环境中，顺序和确认比速度更重要，少一步确认都可能引入故障。

如果你的swap是文件，替换流程就更简单了，新swap文件启用后，直接swapoff旧的swap文件即可。注意不要在swapoff之前删掉swap文件本身，文件已经被内核引用了，删了反而可能出问题。

4. 让swap真正生效：挂载、自动启动与调优

mkswap完成后，只是“格式化”了载体，相当于做好了装备，但还没穿在身上。要让系统真正用上swap，还需要挂载、配置开机自动启动，并适当调优。

4.1 立即启用与临时关闭

即时启用swap，就是swapon命令的活：

bash复制# 启用单个swap设备/文件
swapon /dev/sdb1
swapon /data/swapfile

# 启用所有在 /etc/fstab 中标记为 swap 的设备
swapon -a

# 查看当前所有已启用的swap
swapon --show

同理，关闭swap用swapoff：

bash复制swapoff /dev/sdb1
swapoff /data/swapfile

# 关闭所有swap
swapoff -a

注意：swapoff -a在内存压力大的时候，可能导致内核被迫把所有数据塞回物理内存，瞬间内存不足，甚至触发OOM。所以生产环境执行swapoff时，建议先确保物理内存足够富余，或者先在安全窗口操作。

这里有个小技巧：当你需要临时调整swap大小，比如扩容分区后，可以先swapoff再重新mkswap再swapon。整个过程内存中的数据会先回到物理内存，所以务必在业务低峰期操作。

4.2 开机自动挂载的正确写法

要让swap在重启后依然生效，最标准的方式是写入/etc/fstab。

我的建议是：用UUID来标识swap设备，而不是直接用设备名。因为设备名在开机时依赖内核识别顺序，存在不确定性，而UUID是固定的。执行blkid或者直接看mkswap的输出就能拿到UUID。

一个典型的/etc/fstab swap条目长这样：

bash复制# 设备UUID                                    挂载点 类型      选项    dump pass
UUID=xxxx-xxxx-xxxx-xxxx-xxxx                  none   swap      sw     0    0

如果你用的是swap文件，条目写法略有不同：

bash复制/data/swapfile     none     swap     sw     0     0

注意swap文件的条目第一列是文件绝对路径，不需要UUID，其余列和分区swap保持一致。

写完之后，强烈建议先跑一遍校验再重启：

bash复制# 重新加载fstab配置并尝试挂载所有swap设备
swapon -a

如果返回错误，马上检查fstab的UUID有没有写错。写过一次把UUID打错位的经历，重启后swap没挂载，系统内存很快耗爆，最后在单用户模式下才修复。所以每次改完fstab，都要第一时间用swapon -v校验。

还有一类系统使用systemd管理swap，可以在/lib/systemd/system/下创建一个swap unit文件。比如/etc/systemd/system/swapfile.swap，内容大致是：

ini复制[Unit]
Description=My swap file

[Swap]
What=/data/swapfile
Options=sw

[Install]
WantedBy=multi-user.target

然后执行systemctl enable --now swapfile.swap。这种方式适合喜欢用systemd统一管理的场景，但传统fstab方式在绝大多数发行版上依然是默认且兼容性最好的方案，我建议大部分用户用fstab就够了。

4.3 swappiness：别让swap把性能拖垮

如果说mkswap和swapon决定swap能不能用，那么swappiness参数决定swap用得多“勤快”。这个参数是内核用来调整页面回收策略倾向的，取值范围是0到100。数值越大，内核越积极地使用swap；数值越小，越倾向于回收文件缓存。

默认值通常为60。实际使用中，如果swap使用频繁导致性能下降，可以适当调低：

bash复制# 查看当前值
cat /proc/sys/vm/swappiness

# 临时修改为10
sysctl vm.swappiness=10

# 永久修改
echo "vm.swappiness = 10" >> /etc/sysctl.conf
# 或者用sysctl配置文件（不同发行版路径略有不同）

为什么低一点通常更好？因为swap的操作单位是页，而磁盘随机读写远慢于内存速度，一旦频繁换入换出，系统的响应时间会明显恶化。把swappiness调低，让内核优先保留内存中的进程数据，只回收文件缓存，能有效提升交互式应用的响应速度。

但也不是越低越好。对于某些内存占用高且突发的业务，比如编译任务、科学计算，swap经常被“逼不得已”用上，此时调低swappiness反而可能导致OOM更早出现。所以这个值要根据业务特征综合权衡，建议先在测试环境调几组数值观察比较。

还有另一个参数min_free_kbytes，它决定内核为关键内存分配保留的最小空闲内存量。在一些内存压力较大的机器上适当调高这个值，可以避免内存耗尽时的卡死情况。不过这个参数和swap本身关系没那么直接，这里就不展开了。

5. 常见问题与排查技巧实录

写到这里，做一点“踩坑实录”总结。mkswap这个命令看着简单，用起来却有不少细节容易出错。下面这些问题是这几年来我在实际环境里遇到频率最高的，整理成速查表供大家参考。

5.1 mkswap执行中的高频报错

这里重点说下Device is busy，这是新手最容易碰到的。如果你对一个正在使用的swap分区执行mkswap，系统会直接拒绝。有些同学误以为mkswap会自动帮你停用和重新格式化，其实不会，你必须先swapoff。同理，如果你不小心把swap分区挂载到了某个目录（比如mount /dev/sdb1 /mnt），也要先umount才能执行mkswap。

5.2 生效之后的问题排查

还有一个比较隐蔽的问题：swap文件在根文件系统上做了快照或镜像后，swap文件内容变了，swapon会报错或者导致系统异常。比如有些人用tar备份了swap文件，恢复文件后直接当swap用，结果数据错乱。正确的做法是：swap文件被备份后，恢复出来需要重新mkswap一次，或者更保险的做法是备份时排除swap文件。

5.3 干活时踩过的几个坑

最后分享几个我自己踩出来的经验，这些细节在普通文档里很少写到，但都是真金白银换来的教训。

第一，不要在忙碌的磁盘上做swap。我见过有人把swap建在存放数据库的磁盘上，结果数据库查询高峰期，swap和数据库IO互相争抢，磁盘繁忙度直线飙升。swap空间的IO特点是随机、频繁、大块，和数据库这种顺序读写的模式差别很大，两者放在一起互相拖累。最佳实践是，swap尽量放在独立的磁盘或独立的阵列上，或者至少放在不跑核心业务的盘上。

第二，mkswap之前先看磁盘的队列调度器。如果你用SSD，建议把调度器设为none或mq-deadline，这样swap的随机读写性能会好不少。这个优化看起来是内核层面的，但它直接影响mkswap之后swap的真实使用体验。执行方式参考：

bash复制echo none > /sys/block/sdb/queue/scheduler

当然这只是临时的，持久化可以写到udev规则或rc.local里。

第三，一定要保留好mkswap的输出信息。我在迁移机器时，经常需要根据旧机器swap的UUID重新构建新环境。如果你在配置系统时顺手把mkswap打印的UUID记下来了，后面排障会省很多时间。我一般会把关键信息记录在内部的维护文档里，包括设备、大小、UUID、标签，以及创建时间和服务器用途。一个习惯的养成，能让后续排查少掉一大半头发。

第四，关于swap的监控。既然swap是内存的“救命稻草”，那它的状态就该被纳入监控范围。用zabbix、prometheus或你熟悉的监控工具，加上对swap用量、swap IO、swappiness等指标的监控和告警，能在swap异常使用率飙升时第一时间发现，而不是等系统卡死了才后知后觉。我个人会把swap使用率超过50%作为关注阈值，超过80%触发告警。不同业务可能不同，但至少要有这个监控意识。

结尾：一点个人习惯分享

mkswap这个命令，单独看很简单，但如果把它放进整个swap系统里，涉及的知识点就多了：文件系统的选择、分区规划、内核参数调整、开机自动挂载、性能调优，每一项都值得深入了解。我之所以想在实战篇里把这些串起来，就是因为自己在学习这些命令时，最受益的不是记住几条参数，而是理解了一条命令在系统层面的完整定位。

我个人在实际操作中的习惯是：每次用mkswap之前，都会列一个简单的检查清单，确认设备、确认数据是否备份、确认当前是否有进程在使用目标设备，然后再执行。看似多花了几十秒，但避免过好几次低级事故。另外，如果你管理着多台服务器，不妨把swap相关的信息规范化管理起来，从设备名、UUID到创建日期、合同归属都记清楚，将来做资产盘点、故障排查时，这份记录真的能救命。