接到根分区磁盘空间不足的告警，大概是Linux运维里最不陌生、也最让人心态爆炸的日常之一。尤其当你看到那句“挂载根的磁盘空间太小”，多半意味着根文件系统所在的分区真的快满了——可能是日志没轮转，可能是镜像堆积，也可能是系统当初装的时候就只分了几十个G，压根没考虑后续的数据增长。

这篇文章我不会讲什么高深的理论，就围绕“挂载根的磁盘空间太小”这个最朴素的报错，把排查思路、应急清理、LVM在线扩容、非LVM分区扩容量、虚拟机环境扩容、新增硬盘挂载这些实操全部捋一遍。全程基于我实际踩过的坑来写，该给的命令给全，该说明白的原理讲透，希望能帮遇到同样问题的朋友少走点弯路。

1. 先把“挂载”“根”和“磁盘空间”这几个词串起来理解

很多新手看到“挂载根的磁盘空间太小”会懵，不知道这句报错到底在说哪个盘。这里不绕弯子，直接说结论：这里的“根”指根文件系统，也就是Linux目录树最顶层的那个/目录，而“挂载根”就是把某个存储设备（分区、硬盘、LVM逻辑卷、网络存储等）挂载到了/目录上。系统提示的意思是：/所在的设备空间不够了，需要处理。

1.1 不理解挂载，后面所有操作都容易跑偏

Linux里有个和Windows很不一样的设计：磁盘并不是按C盘、D盘这种“独立门牌号”来访问的，而是统一挂到一棵目录树里。你可以把目录树想象成一颗倒着长的树，/是树根，/home、/var、/tmp这些是树枝，而硬盘分区、U盘、光驱、网络盘都是可以被“接”到某个树枝上的果实。

挂载这个动作，本质上就是把存储设备和某个目录建立关联。一旦关联完成，你往这个目录里写文件，实际写进的就是那块设备上的空间。理解了这一点，再看“挂载根的磁盘空间太小”，本质就是/目录对应的那块设备空间不多了；而/目录通常承载着系统程序、库文件、系统日志、APT缓存等一堆东西，一旦满了，很多服务会直接起不来。

1.2 空间到底被谁吃没的？先有个方向再动手

根目录空间消耗通常有这么几大来源：系统日志（尤其/var/log/journal）、软件包管理器的缓存（/var/cache/apt/archives里的deb包）、容器镜像与容器日志、数据库或应用产生的数据文件，以及用户自己放在/root、/home下的文件。还有一种容易被忽视的：删掉了文件但空间不释放，因为进程还抱着这个被删文件的句柄不放，也就是常说的“空间被僵尸文件占着”。

所以处理顺序应该是：先确认是不是真的满了，再定位占用大头，然后才能决定是靠清理解决，还是必须扩容。很多人一上来就格式化重装或者随便删文件，前者伤筋动骨，后者容易误删系统文件，都属于本末倒置。

2. 应急排查：三步定位空间占用，先把系统“救活”

系统已经告警甚至服务异常的时候，第一目标永远是先腾出空间让系统能跑，然后再考虑根治方案。下面这套排查操作是按顺序来的，省时间，也不容易出错。

2.1 第一步：用df和mount确认实际情况

先看整体水位，再确认挂载关系。执行：

df -h df -i

df -h输出的是每个挂载点的容量、已用、可用和挂载位置。如果看到/这一行的Use%接近100%，那就基本坐实了根分区不足。df -i看的是inode使用率，这是个容易被忽略的指标——inode满了的话，就算磁盘还有空间，系统也会报“No space left on device”，很多人会在这个坑里浪费时间。

紧接着用mount或findmnt确认根目录到底挂在哪个设备上：

findmnt /

输出会告诉你根文件系统类型（ext4、xfs、btrfs等）和设备路径（比如/dev/sda2、/dev/mapper/ubuntu--vg-ubuntu--lv）。这一步很重要，因为后续扩容方案完全取决于根是LVM还是普通分区、文件系统是ext4还是xfs，不同组合操作套路差异很大。

小提示：如果/的使用率在90%以下，但某个具体目录比如/var/log使用率特别高，那不叫根分区不足，而是某个子目录膨胀，直接针对那个目录清理即可。

2.2 第二步：用du逐级排查，找出最占空间的大块头

确认根分区确实满了之后，下一步就是定位占用大头。我的习惯是先从顶层二分下去：

du -h --max-depth=1 / 2>/dev/null | sort -hr

--max-depth=1意味着只看/下每个一级目录的总大小，sort -hr按人类可读大小倒序排列。拿到结果后，体积最大的往往就是/var、/usr或/home。然后再往深入挖：

du -h --max-depth=1 /var 2>/dev/null | sort -hr du -h --max-depth=2 /var/lib 2>/dev/null | sort -hr

一层层剥下去，直到定位到具体的目录或者文件。实际排查中遇到最多的就是/var/lib/docker和/var/log/journal，前者是容器镜像、容器可写层和容器日志的存放处，后者是systemd日志的持久化目录。

2.3 第三步：清理“稳准狠”的临时空间，别乱删生产数据

找出大头之后，可以在排查前先做一轮保守清理，把系统自带的可回收空间先释放出来：

sudo apt clean sudo apt autoremove sudo journalctl --vacuum-size=200M

这段命令的作用分别是：

• apt clean：清空/var/cache/apt/archives里的所有deb安装包缓存。这些包装完就没用了，占用几百MB到一两个G都很正常。
• apt autoremove：卸载系统不再需要的依赖包，能腾出一些空间。
• journalctl --vacuum-size=200M：把systemd日志压缩到200MB以内。日志是根分区膨胀的头号元凶，长期不清理能占好几个G，收缩到合理体积非常有必要。

它们的共同特征是安全：基本不影响系统运行和服务状态，误清的风险极低。执行完再用df -h看一眼，如果空间恢复到可用状态，就可以慢慢规划第二步的扩容了；如果还是红着的，那说明大头在业务数据或容器数据上，需要针对性处理。

3. 根治方案一：LVM根分区在线扩容，最省事的正路

如果系统安装时用了LVM（Ubuntu服务器版默认就是），那扩容路径非常平滑，不需要停机，不需要卸载根分区的挂载，全程可以在线完成。这也是我为什么一直建议生产服务器在安装阶段尽量用LVM的原因——真到了空间不够的这一天，你会庆幸当初多花了五分钟做LVM配置。

3.1 扩容前必须先弄清楚的几个关键概念

LVM管理逻辑卷扩容，本质上就是“物理存储池（VG）里有剩余空间，把它分配给根所在的逻辑卷（LV），然后让文件系统感知这个新大小”。因此扩容前必须确认三点：

1. 物理卷或卷组里还有没有未分配的空间，用vgdisplay或pvs就能看到。
2. 根文件系统当前逻辑卷路径是什么，用lvdisplay或lsblk查看。
3. 文件系统类型是ext4还是xfs，它们扩容用的命令不同——ext4用resize2fs，xfs用xfs_growfs，千万不要混用。

如果VG里已经没有空闲空间，那就要先看物理磁盘是不是也没空间了。如果是虚拟机或云主机，通常在宿主机或云控制台加大磁盘大小之后，再回到系统里用fdisk或者parted处理剩余空间，把新增的空间并入PV，然后继续LV扩容。物理机上如果硬盘槽位有富余，更简单，直接加块新盘，pvcreate再vgextend即可。

3.2 一次完整的LVM在线扩容实操记录

以下是我在一台Ubuntu Server上处理根分区空间不足的真实操作过程，完整记录每一步。

首先看一下当前卷组状态：

sudo vgdisplay

输出里的Free PE / Size一行，就是卷组中还剩余的空间。假设这里显示Free PE / Size 2559 / 10.00 GiB，说明可以拿10G扩展给根逻辑卷。

再用lvdisplay找到根逻辑卷路径。Ubuntu装机时通常会把根卷命名为ubuntu-vg/ubuntu-lv，但不同系统版本命名有差异，最稳妥的方式是到/dev/mapper下去确认，也可以用lsblk -f查看哪些设备挂着/。

确认之后，把空闲空间划给根逻辑卷，可以指定具体大小，也可以直接全部划给根：

sudo lvextend -L +10G /dev/mapper/ubuntu--vg-ubuntu--lv # 或全部剩余空间扩充 sudo lvextend -l +100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv

-L +10G表示增加10G，-l +100%FREE表示把所有剩余空闲空间都给这个逻辑卷。生产环境我建议用-L +指定一个明确增量，比如先加20G，心里有数。

扩容完成后，文件系统还不认识新空间，需要同步调整文件系统。先确认根分区的格式：

lsblk -f /dev/mapper/ubuntu--vg-ubuntu--lv

如果是ext4，执行resize2fs；如果是xfs，执行xfs_growfs。

sudo resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv

命令结束后再执行df -h /，会看到容量和可用空间已经变大，而且云主机上这些操作完全不影响在线服务。

3.3 LVM扩容时文件系统命令容易踩的坑

这里特别提醒几个容易翻车的细节：

• ext4绝不能改成xfs的扩容命令，否则会直接报错，甚至提示需要重新挂载，对在线服务是致命打击。
• resize2fs在ext4上支持在线扩容，但缩减是不推荐且危险的，所以LVM分配空间时最好一次给够，避免以后再来回折腾。
• 在云环境里，如果pvdisplay看到的PV大小还停留在磁盘扩容之前的大小，需要先执行pvresize /dev/vda（或对应设备名），让PV识别到新增的空间，否则vgextend和lvextend都会提示没有可用空间。

xfs环境下，xfs_growfs挂载点和目录都可以指定，建议写成xfs_growfs /，让工具自动识别挂载点所在文件系统的设备，比直接写设备路径容错率更高。

4. 根治方案二：不是LVM，怎么给ext4根分区扩容

不是所有系统都那么幸运是LVM根。很多用自动分区装出来的Linux，根分区就是一个普通的主分区（比如/dev/sda2），文件系统直接建在分区上，没有套LVM那一层。这种情况照样能在线扩容，只是操作路径绕一点，核心手段是growpart配合resize2fs。

4.1 把整个磁盘剩余空间变成根分区的一部分

原理其实很简单：根分区占了磁盘的一部分，后面的磁盘空间是空闲的。我们可以把那个分区的大小直接调大——前提是空闲空必须紧挨着根分区之后，并且磁盘类型是MBR或GPT都能处理。现代系统基本都是GPT分区表，所以用growpart工具是很合适的。

先看当前磁盘分区布局：

sudo lsblk

假设输出显示vda1是根分区，整块盘是vda，且vda剩余空间没有被使用。如果磁盘是在虚拟机上，先把磁盘在宿主机/云控制台扩容到位（比如从50G扩到80G），再回到系统里执行：

sudo growpart /dev/vda 1

这条命令的意思是：把/dev/vda的第1个分区扩大到占满整块磁盘剩余空间。注意/dev/vda和分区号1之间是空格，不能写成/dev/vda1。这是growpart的固定参数格式，经常有人写错导致报错。

分区调整完成后，让内核重新读取分区表。虚拟化环境里partprobe和resize2fs通常就够了；如果提示分区忙，重启一次是最稳妥的：

sudo partprobe /dev/vda

最后扩展文件系统，同样是resize2fs：

sudo resize2fs /dev/vda1

执行完df -h /确认新容量生效即可。

4.2 非LVM扩容的风险点和崩溃恢复经验

这个流程的风险点集中在partition resize这一步，因为直接修改分区表，操作不当可能导致系统无法启动。我自己的体会是：操作前务必先备份分区表信息和建议备份重要数据。可以用sfdisk -d /dev/vda > partition_backup.txt把当前分区表导出备份。真出了意外，这个文件能帮你恢复分区结构。

还有一个非常隐蔽的坑：分区的起始扇区。growpart扩充分区时默认是从分区原有起始位置向后扩大，不会动前面的扇区，所以一般不担心引导数据被破坏。但有些第三方分区工具可能会“优化”起始位置，这就很危险了。所以我的建议是优先用growpart，别贪图图形界面去用其他工具。

如果扩容以后系统启动显示/dev/vda1找不到或文件系统损坏，不要慌。进救援模式，先fsck /dev/vda1检查文件系统，再确认分区表是否被改写。大多数时候是分区表没写对，重新用备份恢复分区表就能救回来。fsck基于ext4的日志，对在线操作过的文件系统修复成功率很高，但一定要在未挂载或只读状态下执行。

5. 虚拟机环境扩容实战：VMware VirtualBox 云主机都适用

平时收到的“根磁盘空间太小”告警，有很大一部分来自虚拟机或云主机。这类环境有个特殊性——你没法给虚拟机随便塞一块物理硬盘进去（云主机更是连机房都碰不到），所以在宿主层面对虚拟磁盘扩容、再进入系统内部调整分区，是最常规的路径。

5.1 宿主机/云控制台层面的磁盘扩容

VMware环境里，可以直接对虚拟机设置里的“硬盘”扩展大小；VirtualBox则在管理界面里调整虚拟硬盘的容量；云平台（阿里云、腾讯云、AWS等）通常在控制台里“扩容云盘”。完成这步后，虚拟机的磁盘“硬件”变大了，但系统里的分区和文件系统还停留在原大小，需要接着做系统层操作。

5.2 系统内部“认领”新空间的完整步骤

进入系统后，如果按lsblk看不到磁盘变大，先执行：

sudo fdisk -l

或lsblk确认系统是否识别到了新磁盘容量。如果容量已经变化但分区未变，那就按前面说的：LVM环境pvresize再lvextend；非LVM环境growpart再resize2fs。

以云上Ubuntu 20.04、根是LVM为例，常见流程如下：

sudo pvresize /dev/vda sudo lvextend -l +100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv sudo resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv

而如果是用growpart方案，就是：

sudo growpart /dev/vda 1 sudo resize2fs /dev/vda1

这里会遇到一个常见问题：growpart提示内核没有更新分区表，执行partprobe无效，这时候不要强行重启生产环境，一般过几秒再试或者用sudo partx -u /dev/vda手动更新。还有一个思路，就是直接reboot，但对于在线服务来说，能避免重启就尽量避免，所以partx -u和partprobe优先尝试。

5.3 虚拟机扩容里容易被忽略的“Windows类型”问题

如果虚拟机里用了Windows系统，或者双系统环境，分区类型可能是NTFS。Linux下给NTFS分区扩容需要ntfsresize，操作又不一样。不过这个问题不属于Linux根分区场景，就不展开了。只提醒一句：在动手之前，先确认文件系统类型比什么都重要。“挂载根”这四个字里没有告诉你文件系统是ext4还是xfs还是别的，只有lsblk -f和findmnt /能给你答案。

6. 除了扩容，还有个“挪空间”的路子：新增硬盘挂载到子目录

扩容是把蛋糕做大，但现实里有时候蛋糕已经没法再做了。比如物理机的磁盘槽位有限，或者云主机磁盘扩容费用高，或者根分区虽然不够但另一块盘还剩很多空间。这时候可以使用Linux的经典思路：把另一块盘挂载到根目录下的某个子目录，把数据迁过去。

6.1 为什么挂新盘比直接把根分区扩到最大更灵活

从管理角度看，根分区保持合理大小（比如50G~100G），把大数据量的目录（/数据、/var/lib/docker、/home这类）单独挂在独立盘上，能避免一个分区故障波及全系统，备份、迁移、快照也都是按目录维度操作的。这是一种非常典型的存储规划思路，也是生产环境比较推荐的做法。

比如机器里新加了一块1T的数据盘，你不想把根扩到1T，就可以把这块盘挂到/data目录。以后所有的大文件都放到/data下，根分区的增长完全可控。

6.2 新增磁盘挂载到目录的操作步骤与fstab配置

流程不复杂，注意细节就行。假设新盘设备是/dev/sdb，你想挂到/data：

sudo mkfs.ext4 /dev/sdb sudo mkdir -p /data sudo mount /dev/sdb /data

但这只能临时挂载一次，重启就失效。所以要写入/etc/fstab实现开机自动挂载。这里我特别提醒：不要直接写设备文件名（如/dev/sdb），因为内核枚举设备顺序可能变化，搞不好重启后设备名就换了，系统会挂载失败甚至卡在启动界面等超时。用UUID才是正路：

sudo blkid /dev/sdb

会输出类似UUID="2febef9a-...-..."的一串。把这一行追加到/etc/fstab：

UUID=2febef9a-...-... /data ext4 defaults 0 2

字段从左到右分别是：设备标识、挂载点、文件系统类型、挂载选项、是否dump备份、fsck检查顺序。根分区是0 1，其他数据分区一般用0 2。写完可以用mount -a测试配置是否正确，若有问题立刻修正，不要直接重启。实测下来，fstab写错是最容易导致重启失败的操作，没有之一。

6.3 数据迁移时“文件被占用”和“目录非空”的实战处理

把数据从根分区挪到新挂载的盘上，不能简单地把目录底下的文件拷走再把盘挂上去，因为目录结构不能直接覆盖。比如要把/var/lib/docker挪到新盘，常规操作顺序是：

1. 停掉docker服务：systemctl stop docker。
2. 把原始目录改名备份：mv /var/lib/docker /var/lib/docker.bak。
3. 创建新目录：mkdir -p /var/lib/docker。
4. 把新盘挂载到/var/lib/docker。
5. 把原数据目录内容拷贝回来：cp -a /var/lib/docker.bak/* /var/lib/docker/，注意-a保留权限、属主、软链接等属性。
6. 启动docker服务，确认数据完整后再删除备份目录：rm -rf /var/lib/docker.bak。

拷贝过程中偶尔会碰到设备空间不足或者进程占用文件的报错。前者是目标盘容量不够，换块更大的盘或精简数据；后者往往需要确保相关服务处于停止状态，如果还有进程占着文件句柄，用lsof +D查看是哪个进程在占用目录，处理完进程再拷贝。还有个细节：直接cp可能碰到稀疏文件或者特殊文件类型报错，如果数据量大，更推荐用rsync：

rsync -av /var/lib/docker.bak/ /var/lib/docker/

rsync支持断点续传，也是我实际用在生产环境最多的同步方式，比cp稳健很多。拷完再执行一次rsync把增量补上，可以有效避免迁移过程中新产生文件造成的遗漏。

6.4 挂载点“目录被占用”时如何无损替换

有时候新盘挂载目录时提示“target is busy”，说明目录里有进程的当前工作目录或者文件被占用。先用lsof找出占用的进程，确认安全后停掉，再重新挂载。

如果目录里已经有重要数据但没地方暂存，可以先挂到临时目录，把数据“搬运”到新盘，再改fstab让开机时挂载到正式目录，最后重启。这样做的本质是避免对访问中的服务做挂载点替换操作，稳妥为先。这个思路也适用于那些“报错挂在根目录上的子目录容量不足、但盘又没法扩”的边界场景。

7. 其他挂载场景里“根空间”相关的疑难杂症

除了上述常见扩容和清理，我在实践中还遇到过一些“挂载、根、磁盘空间”相关的特殊情况，挑几个典型案例扩展说明，帮助大家识别那些不那么直观的陷阱。

7.1 删除文件后空间没释放，最容易被误判为“磁盘满”

明明df -h显示根分区已经满了，du -sh /加出来却很远小于已用空间，或者删除一个大日志文件后可用空间几乎没有增加，这种异常90%是“文件被进程占用”导致的。Linux删除文件时，如果某个进程仍旧持有这个文件的文件描述符，磁盘空间不会真正释放，直到进程退出或重启。

排查手段就是找大文件的同时查占用：

lsof +L1

这个命令列出所有被删除但仍被打开的进程文件。看到结果后重启对应服务，或者直接重启进程，空间就会释放出来。我遇到过一次/var/log/syslog删了三天空间没变化，最后发现是rsyslog进程还抱着句柄，重启rsyslog瞬间释放了十几个G。

7.2 inode耗尽导致“No space left on device”假象

文件系统空间很充裕但写不进数据，还报空间不足，多半是inode耗尽。尤其临时目录或邮件队列里大量小文件场景，几百万个几KB的小文件能瞬间把inode吃干。

用df -i /查看inode使用率。如果接近100%，先删除不必要的海量小文件（比如/tmp下的临时文件、/var/spool/postfix/maildrop下的死信队列），释放inode。如果根文件系统设计时inode数量已经固定，清理无效只能扩容的话，ext4可以新建分区并调整inode密度来承载海量小文件，然后挂到相应目录。创建ext4文件系统时可以mkfs.ext4 -N 10000000 /dev/sdb指定更多inode数量，或者mkfs.ext4 -T small调小inode字节比，为海量小文件场景做好准备。

7.3 虚拟文件系统把根目录空间“撑爆”的另一种玩法

热词里出现了“alist挂载夸克网盘”这种玩法，本质上是用alist这类工具把网盘挂载成了本地目录。这类方案底层是FUSE，看起来是“/根目录下某个挂载点变大了”，但它并不真实消耗磁盘空间——除非程序把网盘文件缓存到本地。alist默认会在本地做分片缓存，如果缓存目录放在根分区下且没有限制大小，网盘数据浏览多了，你会看到根分区的空间被不知名的缓存吃光。

处理方式是检查应用配置里的缓存路径和大小上限，把缓存目录挪到有空间的分区，或者限制缓存上限。这也是“挂了新设备后根空间反而变小”的一类隐藏场景。遇到根空间莫名缩水时，跑一下df -h和du -sh对照使用率，再结合lsof +L1排查，基本都能定位。

7.4 根文件系统只读：文件系统错误导致的挂载异常

还有一类更吓人的问题：系统突然开始报“Read-only file system”，即使root用户也写不进任何文件。通常是因为文件系统检测到异常，内核将其强制置为只读来保护数据。这时候不要反复重启硬试，先进入救援模式或单用户模式，用fsck检查并修复根分区：

sudo umount /dev/sda2 sudo fsck -f /dev/sda2

修复完成后重新挂载。如果修复不了，就要考虑更复杂的数据恢复手段了。这个场景和“空间太小”不完全一样，但是都和根挂载稳定性有关，既然聊到了就顺带提一下。

8. 常用命令速查表与个人避坑心得整理

到这里，核心的操作路径基本都走了一遍。最后我把常用的排查和操作命令汇总成一张速查表，方便大家在实际处理时“抄作业”，再补充几条我自己的心得体会。

最后再说几句实在的。

这套流程我前前后后处理过很多次，最大的感受是——处理根分区空间不足，一定要先定性再行动。先判断是临时占据（日志、缓存、僵尸句柄）还是结构性问题（磁盘本身分小了），再选择清理、扩容、或挂新盘。定性的时间应该占整个处理过程的一半以上，因为手段选错了，后续返工成本极高。比如该扩容的去清日志，清了两个G过两天又满；该挂新盘的硬去扩分区，结果磁盘物理空间压根不够，白忙活一场。

另一点很值得养成习惯：在正常时期就把根分区的“水位”控制好。我一般会让根分区使用率维持在60%以下，至少不要长期超过80%。平时隔段时间看一眼df -h，顺手清一次journalctl和apt clean，远比出问题之后通宵抢救省心得多。监控类工具如果能配上磁盘水位告警，阈值建议设在75%提醒、85%告警，留出反应时间。

如果你发现这篇文章里的某个方案正好匹配你当前遇到的场景，直接照命令抄就可以。扩容这种事，一回生二回熟，多处理几次，再看“挂载根的磁盘空间太小”这种提示，心态就会非常冷静——知道先看什么、再查什么、最后怎么收尾。祝各位的生产环境磁盘永远够用，最好永远用不上这些操作。