接到根分区磁盘空间不足的告警大概是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 -idf -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-depth1 / 2/dev/null | sort -hr--max-depth1意味着只看/下每个一级目录的总大小sort -hr按人类可读大小倒序排列。拿到结果后体积最大的往往就是/var、/usr或/home。然后再往深入挖du -h --max-depth1 /var 2/dev/null | sort -hr du -h --max-depth2 /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-size200M这段命令的作用分别是apt clean清空/var/cache/apt/archives里的所有deb安装包缓存。这些包装完就没用了占用几百MB到一两个G都很正常。apt autoremove卸载系统不再需要的依赖包能腾出一些空间。journalctl --vacuum-size200M把systemd日志压缩到200MB以内。日志是根分区膨胀的头号元凶长期不清理能占好几个G收缩到合理体积非常有必要。它们的共同特征是安全基本不影响系统运行和服务状态误清的风险极低。执行完再用df -h看一眼如果空间恢复到可用状态就可以慢慢规划第二步的扩容了如果还是红着的那说明大头在业务数据或容器数据上需要针对性处理。3. 根治方案一LVM根分区在线扩容最省事的正路如果系统安装时用了LVMUbuntu服务器版默认就是那扩容路径非常平滑不需要停机不需要卸载根分区的挂载全程可以在线完成。这也是我为什么一直建议生产服务器在安装阶段尽量用LVM的原因——真到了空间不够的这一天你会庆幸当初多花了五分钟做LVM配置。3.1 扩容前必须先弄清楚的几个关键概念LVM管理逻辑卷扩容本质上就是“物理存储池VG里有剩余空间把它分配给根所在的逻辑卷LV然后让文件系统感知这个新大小”。因此扩容前必须确认三点物理卷或卷组里还有没有未分配的空间用vgdisplay或pvs就能看到。根文件系统当前逻辑卷路径是什么用lvdisplay或lsblk查看。文件系统类型是ext4还是xfs它们扩容用的命令不同——ext4用resize2fsxfs用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最后扩展文件系统同样是resize2fssudo 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你想挂到/datasudo mkfs.ext4 /dev/sdb sudo mkdir -p /data sudo mount /dev/sdb /data但这只能临时挂载一次重启就失效。所以要写入/etc/fstab实现开机自动挂载。这里我特别提醒不要直接写设备文件名如/dev/sdb因为内核枚举设备顺序可能变化搞不好重启后设备名就换了系统会挂载失败甚至卡在启动界面等超时。用UUID才是正路sudo blkid /dev/sdb会输出类似UUID2febef9a-...-...的一串。把这一行追加到/etc/fstabUUID2febef9a-...-... /data ext4 defaults 0 2字段从左到右分别是设备标识、挂载点、文件系统类型、挂载选项、是否dump备份、fsck检查顺序。根分区是0 1其他数据分区一般用0 2。写完可以用mount -a测试配置是否正确若有问题立刻修正不要直接重启。实测下来fstab写错是最容易导致重启失败的操作没有之一。6.3 数据迁移时“文件被占用”和“目录非空”的实战处理把数据从根分区挪到新挂载的盘上不能简单地把目录底下的文件拷走再把盘挂上去因为目录结构不能直接覆盖。比如要把/var/lib/docker挪到新盘常规操作顺序是停掉docker服务systemctl stop docker。把原始目录改名备份mv /var/lib/docker /var/lib/docker.bak。创建新目录mkdir -p /var/lib/docker。把新盘挂载到/var/lib/docker。把原数据目录内容拷贝回来cp -a /var/lib/docker.bak/* /var/lib/docker/注意-a保留权限、属主、软链接等属性。启动docker服务确认数据完整后再删除备份目录rm -rf /var/lib/docker.bak。拷贝过程中偶尔会碰到设备空间不足或者进程占用文件的报错。前者是目标盘容量不够换块更大的盘或精简数据后者往往需要确保相关服务处于停止状态如果还有进程占着文件句柄用lsof D查看是哪个进程在占用目录处理完进程再拷贝。还有个细节直接cp可能碰到稀疏文件或者特殊文件类型报错如果数据量大更推荐用rsyncrsync -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. 常用命令速查表与个人避坑心得整理到这里核心的操作路径基本都走了一遍。最后我把常用的排查和操作命令汇总成一张速查表方便大家在实际处理时“抄作业”再补充几条我自己的心得体会。需求命令/操作适用场景查看磁盘空间df -h /确认根分区剩余空间查看inode使用df -i /排除inode耗尽导致的假性空间不足查看设备挂载信息findmnt /或mount确认根文件系统类型与设备路径定位大目录du -h --max-depth1 / | sort -hr快速找到空间占用大户查看被删除但占空间的进程lsof L1处理“删了文件但空间没释放”清理APT缓存apt clean释放/var/cache/apt占用限制journal日志journalctl --vacuum-size200M收缩systemd日志查看LVM卷组空闲vgdisplayLVM扩容前必须做的检查LVM逻辑卷扩容lvextend -l 100%FREE lv路径把VG空闲空间全部划给指定LV扩展ext4文件系统resize2fs 设备路径ext4扩容后同步文件系统大小扩展xfs文件系统xfs_growfs /xfs扩容后同步文件系统大小扩大非LVM分区growpart /dev/vda 1把vda1分区扩展到磁盘剩余空间让内核重读分区表partprobe /dev/vda/partx -u /dev/vdagrowpart后的内核更新查询设备UUIDblkid /dev/sdbfstab建议用UUID不用设备名测试fstab配置mount -a检查/etc/fstab是否有错误同步目录带权限rsync -av 源/ 目标/大数据迁移推荐支持续传最后再说几句实在的。这套流程我前前后后处理过很多次最大的感受是——处理根分区空间不足一定要先定性再行动。先判断是临时占据日志、缓存、僵尸句柄还是结构性问题磁盘本身分小了再选择清理、扩容、或挂新盘。定性的时间应该占整个处理过程的一半以上因为手段选错了后续返工成本极高。比如该扩容的去清日志清了两个G过两天又满该挂新盘的硬去扩分区结果磁盘物理空间压根不够白忙活一场。另一点很值得养成习惯在正常时期就把根分区的“水位”控制好。我一般会让根分区使用率维持在60%以下至少不要长期超过80%。平时隔段时间看一眼df -h顺手清一次journalctl和apt clean远比出问题之后通宵抢救省心得多。监控类工具如果能配上磁盘水位告警阈值建议设在75%提醒、85%告警留出反应时间。如果你发现这篇文章里的某个方案正好匹配你当前遇到的场景直接照命令抄就可以。扩容这种事一回生二回熟多处理几次再看“挂载根的磁盘空间太小”这种提示心态就会非常冷静——知道先看什么、再查什么、最后怎么收尾。祝各位的生产环境磁盘永远够用最好永远用不上这些操作。