1. 问题现场当你的Ubuntu系统突然“窒息”那天下午我正在服务器上部署一个关键的微服务docker-compose up命令执行到一半终端突然弹出一行刺眼的红色错误No space left on device。心里咯噔一下赶紧敲下df -h查看磁盘使用情况。果不其然根目录/对应的文件系统/dev/mapper/ubuntu--vg-ubuntu--lv使用率赫然显示着 100%。这就像你正开着车在高速上狂奔仪表盘突然亮起油箱见底的警报而下一个服务区还在几十公里外。/dev/mapper/ubuntu--vg-ubuntu--lv这个看起来有点复杂的名字对于很多使用 Ubuntu 官方镜像或某些自动安装脚本的用户来说其实是个“老熟人”。它不是一个物理硬盘比如/dev/sda1而是一个逻辑卷。简单来说你的物理硬盘/dev/sda被划分成几个部分其中一个叫 LVM 的“超级管理员”接管了。这个管理员把物理空间做成一个大池子卷组 VG然后从这个池子里划出一块逻辑区域逻辑卷 LV给你当根分区用。这样做的好处是灵活空间不够了可以从池子里再划一点不用像传统分区那样死板。但坏处是对于不熟悉 LVM 的朋友来说当这个逻辑卷满了的时候扩容操作会比直接扩一个/dev/sda2分区要绕几个弯。这个问题太常见了。无论是跑在云服务器上的 Ubuntu还是本地虚拟机里做开发的系统默认的磁盘分配往往比较保守。随着你不断安装软件、拉取 Docker 镜像、写入日志文件根分区被慢慢蚕食直到某一天突然“爆仓”。搜索引擎里“ubuntu 根目录 100%”、“/dev/mapper 空间不足”的热度常年不减正说明了其普遍性。所以如果你也遇到了同样的困境别慌。这篇文章就是带你一步步走通整个排查和扩容流程的实战手册。我们将从确认问题根源开始一路讲到如何安全地给这个逻辑卷“增肥”过程中我会穿插我踩过的坑和总结的经验确保你不仅能解决问题还能真正理解背后的逻辑。无论你是运维工程师、开发者还是正在学习 Linux 的爱好者这套方法都适用。2. 诊断与确认你的磁盘到底被谁吃掉了在动手扩容之前盲目操作是危险的。我们必须先像医生一样给系统做一个全面的“体检”搞清楚空间到底被哪些文件占用了以及我们的 LVM 结构是否还有“余粮”可用。这一步至关重要它能避免你走弯路甚至误操作导致数据丢失。2.1 使用经典命令进行全局扫描首先我们得用df -h命令确认一下“病患”是谁以及“病情”有多严重。df -h你会看到类似下面的输出文件系统 容量 已用 可用 已用% 挂载点 udev 3.9G 0 3.9G 0% /dev tmpfs 796M 1.7M 795M 1% /run /dev/mapper/ubuntu--vg-ubuntu--lv 19G 18G 0 100% / tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/sda2 1.5G 250M 1.2G 18% /boot tmpfs 796M 0 796M 0% /run/user/1000重点看/dev/mapper/ubuntu--vg-ubuntu--lv这一行它挂载在根目录/已用空间 18G总容量 19G使用率 100%。这证实了我们的判断。接下来我们需要知道是哪些“大胃王”文件吃掉了空间。这里有两个神器du命令用于估算文件和目录的磁盘使用空间。我们可以用它来逐级深入查找。ncdu工具一个基于ncurses库的du命令行版本交互式界面直观又好用。如果系统没有可以用sudo apt install ncdu安装。我个人的习惯是先快速用du扫一下常用的大目录sudo du -sh /* 2/dev/null | sort -hr | head -20这条命令的意思是以人类可读的格式-h统计根目录下所有一级目录的总大小-s将错误信息如权限不足重定向到黑洞2/dev/null然后按人类可读的数字逆序排序-hr最后显示前20个。你可能会看到/var、/usr、/home这几个目录名列前茅。然后我会使用ncdu进行更精细的定位。直接在根目录运行sudo ncdu /它会扫描整个文件系统然后呈现一个可交互的界面。你可以用上下键选择目录按回车键进入它会实时显示该目录下各子项的大小占比。通常罪魁祸首会在以下几个地方/var 这是“变量”数据的天堂也是空间杀手的老巢。重点关注/var/log 系统日志和应用程序日志。特别是像journalctl的日志、Docker 容器日志如果存储在默认位置、Nginx/Apache 的访问日志和错误日志。/var/lib/docker Docker 的默认存储目录包含了所有的镜像、容器、卷和构建缓存。这是最常见的“空间吞噬者”之一。/var/cache 软件包的缓存比如apt的缓存 (/var/cache/apt/archives)。/tmp 临时文件目录但有时某些程序异常退出会留下大文件。/home 用户目录如果你在那里存放了大文件或下载了大型资源。/usr 系统软件和库通常比较稳定但安装了大量开发包后也可能很大。经验之谈 在虚拟机或Docker容器里/var/lib/docker和/var/log是首要怀疑对象。有一次我遇到一个容器的日志配置错误单个日志文件就滚到了几十个G直接用truncate命令清空它sudo truncate -s 0 /var/log/some-huge.log或者配置日志轮转logrotate就能瞬间释放大量空间。2.2 探查 LVM 的“家底”还有多少余粮可扩确定了是根逻辑卷满了我们还得看看 LVM 的“资源池”里还有没有空闲的“粮食”物理空间可以分配给它。这就需要用到 LVM 的一系列管理命令。首先查看当前的逻辑卷LV信息sudo lvdisplay在输出中找到你的根逻辑卷通常是ubuntu-vg/ubuntu-lv关注这几个关键字段LV Path/dev/ubuntu-vg/ubuntu-lv这就是df里/dev/mapper/ubuntu--vg-ubuntu--lv的另一个名字破折号被转换了。LV Size 当前逻辑卷的大小比如 19 GiB。VG Name 它所属的卷组Volume Group名字这里是ubuntu-vg。接着查看这个卷组VG的详细信息看看池子里总共有多少空间用了多少还剩多少sudo vgdisplay ubuntu-vg重点关注VG Size 卷组的总大小。Alloc PE / Size 已经分配出去的物理块PE和大小。Free PE / Size空闲的物理块和大小这是我们的“余粮”。如果Free PE / Size大于 0比如显示有 10 GiB 空闲那么恭喜你可以直接进行步骤3从池子里划拨空间给逻辑卷。这是最简单的情况。但是很多时候你会发现Free PE / Size是 0。这意味着卷组这个“池子”本身也满了没有空闲空间可以分配。这时我们就需要先给这个“池子”加水也就是步骤4为卷组添加新的物理存储比如给虚拟机添加一块新硬盘或者扩展现有物理硬盘的分区。踩坑记录 曾经有一次我在云平台上给虚拟机“热添加”了一块硬盘系统识别为/dev/sdb。我兴冲冲地直接把它做成物理卷PV加入卷组然后扩展逻辑卷。结果重启后系统无法识别/dev/sdb导致卷组损坏系统无法启动。后来才知道云平台热添加的磁盘设备名可能不稳定最好使用磁盘的 UUID 或by-id路径来创建 PV。这个教训我们会在后面详细讲。在开始动手扩容前请务必根据vgdisplay的结果明确你处于哪种情况情况A理想vgdisplay显示有Free Size。 → 直接跳到第3章。情况B常见vgdisplay显示Free Size为 0。 → 你需要先阅读第4章为卷组扩容。3. 情况A从卷组“池子”里分配空间给逻辑卷如果你的vgdisplay显示卷组VG有空闲空间那么扩容逻辑卷LV就相对简单。整个过程可以概括为三步扩展逻辑卷LV的大小-通知操作系统磁盘容量变了-扩展文件系统以使用新空间。请注意以下操作通常可以在线进行无需重启但强烈建议先对重要数据进行备份。3.1 第一步扩展逻辑卷LV的大小假设我们检查到ubuntu-vg卷组有 10 GiB 的空闲空间我们决定将其全部分配给根逻辑卷ubuntu-lv。使用lvextend命令# 扩展逻辑卷将卷组中所有空闲空间都分配给它 sudo lvextend -l 100%FREE /dev/ubuntu-vg/ubuntu-lv # 或者如果你只想扩展特定大小比如5G # sudo lvextend -L 5G /dev/ubuntu-vg/ubuntu-lv命令解释-l 100%FREE 这是一个非常方便的参数表示“使用卷组中100%的空闲空间”。这避免了你去计算复杂的PE数量。-L 5G 如果你明确知道要扩展多少可以用-L指定绝对大小-L 25G或增量大小-L 5G。/dev/ubuntu-vg/ubuntu-lv 目标逻辑卷的设备路径。执行成功后你会看到类似Size of logical volume ubuntu-vg/ubuntu-lv changed from 19.00 GiB (4863 extents) to 29.00 GiB (7423 extents).的输出。这意味着逻辑卷的“容器”变大了但里面的“文件系统”还没有感知到这个变化。3.2 第二步扩展文件系统以填充逻辑卷这是最关键也最容易出错的一步。逻辑卷就像一个盒子文件系统是盒子里的收纳格。我们刚刚把盒子换大了lvextend但里面的收纳格还是原来的布局。现在需要调整收纳格resize2fs或xfs_growfs来填满新盒子。首先你必须确认根分区使用的文件系统类型使用lsblk -f或df -T查看。df -T /dev/mapper/ubuntu--vg-ubuntu--lv常见的两种类型及对应操作1. 如果是 ext4 (或 ext2/ext3) 文件系统使用resize2fs命令。这个命令非常智能如果你不指定大小它会自动调整到逻辑卷的当前最大容量。# 对于 ext2/3/4这是最常用的命令 sudo resize2fs /dev/ubuntu-vg/ubuntu-lv或者如果你想指定一个确切的大小通常不需要sudo resize2fs /dev/ubuntu-vg/ubuntu-lv 25G执行后你会看到类似The filesystem on /dev/ubuntu-vg/ubuntu-lv is now 7601152 (4k) blocks long.的信息。2. 如果是 XFS 文件系统XFS 文件系统只能增大不能缩小。使用xfs_growfs命令并且需要指定挂载点而不是设备路径。# 对于 XFS必须指定挂载点 sudo xfs_growfs /执行后会输出当前和新的大小信息。核心原理与避坑指南顺序绝对不能错 一定是先lvextend扩盒子再resize2fs/xfs_growfs扩收纳格。反过来会导致灾难。在线操作 对于 ext4 和 XFS只要文件系统处于挂载状态我们的根分区肯定是挂载的就可以直接在线扩容这是 LVM 的一大优势。检查结果 操作完成后再次运行df -h你应该能看到根分区的“容量”和“可用”空间都变大了。为什么不用-r参数lvextend有一个-r(--resizefs) 参数可以一步完成逻辑卷和文件系统的扩展。这很方便但我个人在关键生产环境倾向于分两步走。原因有二一是分步操作更清晰便于在中间步骤检查状态二是在某些老版本或特定发行版上-r参数的支持可能不完美。对于新手使用-r参数是更安全的选择sudo lvextend -r -l 100%FREE /dev/ubuntu-vg/ubuntu-lv。完成这两步后你的根分区就应该已经成功扩容了。可以运行df -h和lvdisplay来验证。如果vgdisplay显示没有空闲空间了而df -h显示根分区空间充足那么恭喜你问题解决4. 情况B卷组已满需要先为卷组“扩容”这是更常见、也更复杂一些的场景。vgdisplay显示Free Size为 0意味着 LVM 的“资源池”已经枯竭。我们必须先向这个池子里注入新的“水”——即添加新的物理存储空间。这通常有两种途径扩展现有的物理硬盘 如果你的系统是虚拟机如 VMware, VirtualBox, KVM或者云服务器如 AWS EBS, 阿里云云盘并且底层硬盘支持在线扩容你可以先扩大虚拟硬盘的容量。添加一块新的物理硬盘 给服务器插上一块新硬盘或者在虚拟机里添加一块新虚拟硬盘。无论哪种途径最终在操作系统层面你都会获得一个新的存储设备比如/dev/sdb或一个变大的现有分区比如/dev/sda3。我们的目标是将这个新的存储空间做成 LVM 的“砖块”物理卷 PV然后加入到现有的“池子”卷组 VG中。4.1 途径一扩展现有物理硬盘虚拟机/云环境常见假设你的根分区在/dev/sda上并且sda后面还有未分配的空间比如你在虚拟机管理界面将硬盘从 50G 扩到了 100G。第一步让操作系统识别新的磁盘容量。对于虚拟机热添加后可能需要让内核重新读取分区表# 尝试让 SCSI 主机重新扫描设备对虚拟机有效 sudo echo 1 /sys/class/scsi_host/host0/scan sudo echo 1 /sys/class/scsi_host/host1/scan # 或者使用更通用的方法 sudo partprobe然后使用lsblk或fdisk -l查看/dev/sda的总容量是否已经变大。第二步扩展包含 PV 的分区。关键点来了LVM 的物理卷PV是创建在磁盘分区如/dev/sda3上的而不是整个磁盘/dev/sda。所以你需要扩展的是那个承载着 PV 的分区。使用pvs或pvdisplay命令查看当前 PV 创建在哪个设备上。假设是/dev/sda3。使用fdisk或parted工具删除旧的分区/dev/sda3并创建一个新的、更大的分区。注意删除分区不会丢失其上的 LVM 数据因为 LVM 元数据在分区内部但操作仍需谨慎使用sudo fdisk /dev/sda。输入p打印分区表记住/dev/sda3的起始扇区Start。输入d然后输入分区号3删除它。输入n创建新分区选择主分区或逻辑分区和原来一致分区号必须还是 3。当询问起始扇区时输入刚才记下的原起始扇区这一点至关重要确保起始位置和原来完全一样。当询问结束扇区时直接回车使用所有可用空间。输入t更改分区类型选择分区3将其类型设置为8e(Linux LVM)。输入p确认新分区表确保/dev/sda3的起始扇区没变但结束扇区变大了。输入w写入并退出。重启系统或使用partprobe让内核重新加载分区表。有时重启是最稳妥的。第三步扩展物理卷PV本身。分区变大了但上面的 PV 还没变。使用pvresize命令告诉 LVM 这个 PV 的容量变了。sudo pvresize /dev/sda3运行pvdisplay /dev/sda3你会看到PV Size变大了并且多出了Free PE。至此卷组VG的“池子”里就有了新的空闲空间。现在你可以回到第3章使用lvextend和resize2fs来扩展你的逻辑卷了。4.2 途径二添加新硬盘并加入卷组假设你添加了一块新硬盘系统识别为/dev/sdb。第一步在新硬盘上创建物理卷PV。sudo pvcreate /dev/sdb如果系统提示设备/dev/sdb上可能有现有签名可以加上-f参数强制创建sudo pvcreate -f /dev/sdb。第二步将新的物理卷PV加入到现有的卷组VG中。sudo vgextend ubuntu-vg /dev/sdb现在运行vgdisplay ubuntu-vg你应该能看到VG Size变大了并且有了可观的Free Size。重大避坑提示关于设备名稳定性在物理服务器或某些虚拟化环境下磁盘设备名如/dev/sdb可能在重启后发生变化例如变成/dev/sdc。如果 LVM 仅通过设备名来识别 PV这会导致卷组无法激活进而导致系统无法启动。解决方案使用磁盘的稳定标识符如/dev/disk/by-id/或/dev/disk/by-uuid/来创建 PV。找到新硬盘的稳定路径ls -l /dev/disk/by-id/找到对应sdb的条目通常类似ata-VENDOR_MODEL_SERIAL或wwn-0x500xxxx。使用这个路径创建 PV 和扩展 VGsudo pvcreate /dev/disk/by-id/ata-VENDOR_MODEL_SERIAL sudo vgextend ubuntu-vg /dev/disk/by-id/ata-VENDOR_MODEL_SERIAL这样无论设备名怎么变LVM 都能通过唯一的 ID 找到它。这是我用一次惨痛的数据恢复经历换来的经验。完成以上任一途径后你的卷组就有了新的空闲空间。此时流程就回到了情况A。你可以按照第3章的步骤使用lvextend和resize2fs/xfs_growfs来最终扩展你的根逻辑卷。5. 扩容后的善后与进阶思考成功扩容并验证df -h显示空间充足后工作并没有完全结束。作为一个负责任的系统管理者我们还需要做一些善后工作并思考如何避免问题再次发生。5.1 验证与监控首先进行一次简单的写入测试确保新空间是可用的# 创建一个1GB的大文件测试写入 sudo dd if/dev/zero of/testfile bs1M count1024 # 检查文件是否创建成功 ls -lh /testfile # 删除测试文件 sudo rm /testfile其次建立监控。空间问题不应该等到 100% 才被发现。你可以配置告警 使用像PrometheusNode ExporterGrafana或Zabbix这样的监控系统对磁盘使用率设置告警阈值例如 85%。简易脚本 写一个简单的 Shell 脚本通过df或du定期检查并通过邮件或即时通讯工具发送报警。#!/bin/bash THRESHOLD90 USAGE$(df -h / | awk NR2 {print $5} | sed s/%//) if [ $USAGE -gt $THRESHOLD ]; then echo 警告根分区使用率 ${USAGE}% 超过阈值 ${THRESHOLD}% | mail -s 磁盘空间告警 adminexample.com fi然后将这个脚本加入crontab定时执行。5.2 根治空间消耗清理与规划扩容是“治标”清理和规划才是“治本”。回顾第2章我们找到的空间占用大户进行针对性清理清理 Docker Docker 是著名的“空间吞噬兽”。# 删除所有已停止的容器 docker container prune # 删除所有未被使用的镜像、容器卷和网络谨慎会删除悬空镜像 docker system prune -a # 更激进地清理所有构建缓存 docker builder prune考虑为 Docker 配置存储驱动选项或者将 Docker 的数据目录 (/var/lib/docker) 迁移到更大的独立分区。清理 APT 缓存sudo apt clean # 删除所有已下载的 .deb 包 sudo apt autoclean # 删除旧版本的 .deb 包 sudo apt autoremove # 删除自动安装且不再需要的依赖包管理日志检查/var/log目录下的大文件。使用journalctl清理系统日志# 只保留最近两天的日志 sudo journalctl --vacuum-time2d # 或者限制日志占用的最大磁盘空间 sudo journalctl --vacuum-size500M确保logrotate服务正常运行它负责自动轮转和压缩旧日志。查找并删除特定大文件# 查找大于100M的文件 sudo find / -type f -size 100M -exec ls -lh {} \; 2/dev/null | sort -k5,5hr5.3 架构层面的预防更好的分区方案对于新部署的系统为了避免根分区空间不足的窘境可以考虑更合理的分区方案独立分区 将/home、/var、/opt等容易增长的用户数据和应用程序目录单独分区。即使它们满了也不会影响根分区的系统运行。使用 LVM 并预留空间 在安装系统时就使用 LVM并为卷组VG分配比逻辑卷LV更多的空间。例如给一个 100G 的硬盘只给根逻辑卷分配 30G剩下的 70G 留在卷组池子里。这样未来扩容会非常灵活。云原生思路 对于容器化环境考虑使用宿主机的独立目录或网络存储如 NFS、Ceph来挂载容器的持久化数据完全避免容器日志和缓存挤占系统盘。5.4 关于“减容”的严肃警告在搜索热词里你可能会看到“lvm逻辑卷 扩容 减容”。这里我必须给出一个强烈警告对于根分区或者任何包含重要数据且已使用的逻辑卷在线缩小减容是极其危险的操作不推荐在生产环境尝试。虽然 LVM 理论上支持使用lvreduce缩小逻辑卷但这要求你先使用resize2fs仅限 ext2/3/4缩小文件系统。这个过程复杂容易出错并且任何一步失误都可能导致数据全部丢失。XFS 文件系统甚至根本不支持缩小。因此除非在测试环境或有绝对充分备份和回滚方案的情况下否则请将“减容”视为禁区。规划时保守一点多分配一些空间远比事后冒险缩容要安全得多。处理/dev/mapper/ubuntu--vg-ubuntu--lv空间不足的问题是一次典型的 Linux 系统运维实战。它考验的不仅是对命令的熟悉程度更是对存储架构物理磁盘 - 分区 - PV - VG - LV - 文件系统的清晰理解。从精准诊断、审慎操作到事后优化每一步都需要耐心和细心。希望这篇详细的指南能帮你不仅解决眼前的问题更能建立起一套应对此类问题的系统性方法论。记住在按下回车键执行任何可能影响数据的命令前多一次确认总好过事后的追悔莫及。
1. 问题现场当你的Ubuntu系统突然“窒息”那天下午我正在服务器上部署一个关键的微服务docker-compose up命令执行到一半终端突然弹出一行刺眼的红色错误No space left on device。心里咯噔一下赶紧敲下df -h查看磁盘使用情况。果不其然根目录/对应的文件系统/dev/mapper/ubuntu--vg-ubuntu--lv使用率赫然显示着 100%。这就像你正开着车在高速上狂奔仪表盘突然亮起油箱见底的警报而下一个服务区还在几十公里外。/dev/mapper/ubuntu--vg-ubuntu--lv这个看起来有点复杂的名字对于很多使用 Ubuntu 官方镜像或某些自动安装脚本的用户来说其实是个“老熟人”。它不是一个物理硬盘比如/dev/sda1而是一个逻辑卷。简单来说你的物理硬盘/dev/sda被划分成几个部分其中一个叫 LVM 的“超级管理员”接管了。这个管理员把物理空间做成一个大池子卷组 VG然后从这个池子里划出一块逻辑区域逻辑卷 LV给你当根分区用。这样做的好处是灵活空间不够了可以从池子里再划一点不用像传统分区那样死板。但坏处是对于不熟悉 LVM 的朋友来说当这个逻辑卷满了的时候扩容操作会比直接扩一个/dev/sda2分区要绕几个弯。这个问题太常见了。无论是跑在云服务器上的 Ubuntu还是本地虚拟机里做开发的系统默认的磁盘分配往往比较保守。随着你不断安装软件、拉取 Docker 镜像、写入日志文件根分区被慢慢蚕食直到某一天突然“爆仓”。搜索引擎里“ubuntu 根目录 100%”、“/dev/mapper 空间不足”的热度常年不减正说明了其普遍性。所以如果你也遇到了同样的困境别慌。这篇文章就是带你一步步走通整个排查和扩容流程的实战手册。我们将从确认问题根源开始一路讲到如何安全地给这个逻辑卷“增肥”过程中我会穿插我踩过的坑和总结的经验确保你不仅能解决问题还能真正理解背后的逻辑。无论你是运维工程师、开发者还是正在学习 Linux 的爱好者这套方法都适用。2. 诊断与确认你的磁盘到底被谁吃掉了在动手扩容之前盲目操作是危险的。我们必须先像医生一样给系统做一个全面的“体检”搞清楚空间到底被哪些文件占用了以及我们的 LVM 结构是否还有“余粮”可用。这一步至关重要它能避免你走弯路甚至误操作导致数据丢失。2.1 使用经典命令进行全局扫描首先我们得用df -h命令确认一下“病患”是谁以及“病情”有多严重。df -h你会看到类似下面的输出文件系统 容量 已用 可用 已用% 挂载点 udev 3.9G 0 3.9G 0% /dev tmpfs 796M 1.7M 795M 1% /run /dev/mapper/ubuntu--vg-ubuntu--lv 19G 18G 0 100% / tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/sda2 1.5G 250M 1.2G 18% /boot tmpfs 796M 0 796M 0% /run/user/1000重点看/dev/mapper/ubuntu--vg-ubuntu--lv这一行它挂载在根目录/已用空间 18G总容量 19G使用率 100%。这证实了我们的判断。接下来我们需要知道是哪些“大胃王”文件吃掉了空间。这里有两个神器du命令用于估算文件和目录的磁盘使用空间。我们可以用它来逐级深入查找。ncdu工具一个基于ncurses库的du命令行版本交互式界面直观又好用。如果系统没有可以用sudo apt install ncdu安装。我个人的习惯是先快速用du扫一下常用的大目录sudo du -sh /* 2/dev/null | sort -hr | head -20这条命令的意思是以人类可读的格式-h统计根目录下所有一级目录的总大小-s将错误信息如权限不足重定向到黑洞2/dev/null然后按人类可读的数字逆序排序-hr最后显示前20个。你可能会看到/var、/usr、/home这几个目录名列前茅。然后我会使用ncdu进行更精细的定位。直接在根目录运行sudo ncdu /它会扫描整个文件系统然后呈现一个可交互的界面。你可以用上下键选择目录按回车键进入它会实时显示该目录下各子项的大小占比。通常罪魁祸首会在以下几个地方/var 这是“变量”数据的天堂也是空间杀手的老巢。重点关注/var/log 系统日志和应用程序日志。特别是像journalctl的日志、Docker 容器日志如果存储在默认位置、Nginx/Apache 的访问日志和错误日志。/var/lib/docker Docker 的默认存储目录包含了所有的镜像、容器、卷和构建缓存。这是最常见的“空间吞噬者”之一。/var/cache 软件包的缓存比如apt的缓存 (/var/cache/apt/archives)。/tmp 临时文件目录但有时某些程序异常退出会留下大文件。/home 用户目录如果你在那里存放了大文件或下载了大型资源。/usr 系统软件和库通常比较稳定但安装了大量开发包后也可能很大。经验之谈 在虚拟机或Docker容器里/var/lib/docker和/var/log是首要怀疑对象。有一次我遇到一个容器的日志配置错误单个日志文件就滚到了几十个G直接用truncate命令清空它sudo truncate -s 0 /var/log/some-huge.log或者配置日志轮转logrotate就能瞬间释放大量空间。2.2 探查 LVM 的“家底”还有多少余粮可扩确定了是根逻辑卷满了我们还得看看 LVM 的“资源池”里还有没有空闲的“粮食”物理空间可以分配给它。这就需要用到 LVM 的一系列管理命令。首先查看当前的逻辑卷LV信息sudo lvdisplay在输出中找到你的根逻辑卷通常是ubuntu-vg/ubuntu-lv关注这几个关键字段LV Path/dev/ubuntu-vg/ubuntu-lv这就是df里/dev/mapper/ubuntu--vg-ubuntu--lv的另一个名字破折号被转换了。LV Size 当前逻辑卷的大小比如 19 GiB。VG Name 它所属的卷组Volume Group名字这里是ubuntu-vg。接着查看这个卷组VG的详细信息看看池子里总共有多少空间用了多少还剩多少sudo vgdisplay ubuntu-vg重点关注VG Size 卷组的总大小。Alloc PE / Size 已经分配出去的物理块PE和大小。Free PE / Size空闲的物理块和大小这是我们的“余粮”。如果Free PE / Size大于 0比如显示有 10 GiB 空闲那么恭喜你可以直接进行步骤3从池子里划拨空间给逻辑卷。这是最简单的情况。但是很多时候你会发现Free PE / Size是 0。这意味着卷组这个“池子”本身也满了没有空闲空间可以分配。这时我们就需要先给这个“池子”加水也就是步骤4为卷组添加新的物理存储比如给虚拟机添加一块新硬盘或者扩展现有物理硬盘的分区。踩坑记录 曾经有一次我在云平台上给虚拟机“热添加”了一块硬盘系统识别为/dev/sdb。我兴冲冲地直接把它做成物理卷PV加入卷组然后扩展逻辑卷。结果重启后系统无法识别/dev/sdb导致卷组损坏系统无法启动。后来才知道云平台热添加的磁盘设备名可能不稳定最好使用磁盘的 UUID 或by-id路径来创建 PV。这个教训我们会在后面详细讲。在开始动手扩容前请务必根据vgdisplay的结果明确你处于哪种情况情况A理想vgdisplay显示有Free Size。 → 直接跳到第3章。情况B常见vgdisplay显示Free Size为 0。 → 你需要先阅读第4章为卷组扩容。3. 情况A从卷组“池子”里分配空间给逻辑卷如果你的vgdisplay显示卷组VG有空闲空间那么扩容逻辑卷LV就相对简单。整个过程可以概括为三步扩展逻辑卷LV的大小-通知操作系统磁盘容量变了-扩展文件系统以使用新空间。请注意以下操作通常可以在线进行无需重启但强烈建议先对重要数据进行备份。3.1 第一步扩展逻辑卷LV的大小假设我们检查到ubuntu-vg卷组有 10 GiB 的空闲空间我们决定将其全部分配给根逻辑卷ubuntu-lv。使用lvextend命令# 扩展逻辑卷将卷组中所有空闲空间都分配给它 sudo lvextend -l 100%FREE /dev/ubuntu-vg/ubuntu-lv # 或者如果你只想扩展特定大小比如5G # sudo lvextend -L 5G /dev/ubuntu-vg/ubuntu-lv命令解释-l 100%FREE 这是一个非常方便的参数表示“使用卷组中100%的空闲空间”。这避免了你去计算复杂的PE数量。-L 5G 如果你明确知道要扩展多少可以用-L指定绝对大小-L 25G或增量大小-L 5G。/dev/ubuntu-vg/ubuntu-lv 目标逻辑卷的设备路径。执行成功后你会看到类似Size of logical volume ubuntu-vg/ubuntu-lv changed from 19.00 GiB (4863 extents) to 29.00 GiB (7423 extents).的输出。这意味着逻辑卷的“容器”变大了但里面的“文件系统”还没有感知到这个变化。3.2 第二步扩展文件系统以填充逻辑卷这是最关键也最容易出错的一步。逻辑卷就像一个盒子文件系统是盒子里的收纳格。我们刚刚把盒子换大了lvextend但里面的收纳格还是原来的布局。现在需要调整收纳格resize2fs或xfs_growfs来填满新盒子。首先你必须确认根分区使用的文件系统类型使用lsblk -f或df -T查看。df -T /dev/mapper/ubuntu--vg-ubuntu--lv常见的两种类型及对应操作1. 如果是 ext4 (或 ext2/ext3) 文件系统使用resize2fs命令。这个命令非常智能如果你不指定大小它会自动调整到逻辑卷的当前最大容量。# 对于 ext2/3/4这是最常用的命令 sudo resize2fs /dev/ubuntu-vg/ubuntu-lv或者如果你想指定一个确切的大小通常不需要sudo resize2fs /dev/ubuntu-vg/ubuntu-lv 25G执行后你会看到类似The filesystem on /dev/ubuntu-vg/ubuntu-lv is now 7601152 (4k) blocks long.的信息。2. 如果是 XFS 文件系统XFS 文件系统只能增大不能缩小。使用xfs_growfs命令并且需要指定挂载点而不是设备路径。# 对于 XFS必须指定挂载点 sudo xfs_growfs /执行后会输出当前和新的大小信息。核心原理与避坑指南顺序绝对不能错 一定是先lvextend扩盒子再resize2fs/xfs_growfs扩收纳格。反过来会导致灾难。在线操作 对于 ext4 和 XFS只要文件系统处于挂载状态我们的根分区肯定是挂载的就可以直接在线扩容这是 LVM 的一大优势。检查结果 操作完成后再次运行df -h你应该能看到根分区的“容量”和“可用”空间都变大了。为什么不用-r参数lvextend有一个-r(--resizefs) 参数可以一步完成逻辑卷和文件系统的扩展。这很方便但我个人在关键生产环境倾向于分两步走。原因有二一是分步操作更清晰便于在中间步骤检查状态二是在某些老版本或特定发行版上-r参数的支持可能不完美。对于新手使用-r参数是更安全的选择sudo lvextend -r -l 100%FREE /dev/ubuntu-vg/ubuntu-lv。完成这两步后你的根分区就应该已经成功扩容了。可以运行df -h和lvdisplay来验证。如果vgdisplay显示没有空闲空间了而df -h显示根分区空间充足那么恭喜你问题解决4. 情况B卷组已满需要先为卷组“扩容”这是更常见、也更复杂一些的场景。vgdisplay显示Free Size为 0意味着 LVM 的“资源池”已经枯竭。我们必须先向这个池子里注入新的“水”——即添加新的物理存储空间。这通常有两种途径扩展现有的物理硬盘 如果你的系统是虚拟机如 VMware, VirtualBox, KVM或者云服务器如 AWS EBS, 阿里云云盘并且底层硬盘支持在线扩容你可以先扩大虚拟硬盘的容量。添加一块新的物理硬盘 给服务器插上一块新硬盘或者在虚拟机里添加一块新虚拟硬盘。无论哪种途径最终在操作系统层面你都会获得一个新的存储设备比如/dev/sdb或一个变大的现有分区比如/dev/sda3。我们的目标是将这个新的存储空间做成 LVM 的“砖块”物理卷 PV然后加入到现有的“池子”卷组 VG中。4.1 途径一扩展现有物理硬盘虚拟机/云环境常见假设你的根分区在/dev/sda上并且sda后面还有未分配的空间比如你在虚拟机管理界面将硬盘从 50G 扩到了 100G。第一步让操作系统识别新的磁盘容量。对于虚拟机热添加后可能需要让内核重新读取分区表# 尝试让 SCSI 主机重新扫描设备对虚拟机有效 sudo echo 1 /sys/class/scsi_host/host0/scan sudo echo 1 /sys/class/scsi_host/host1/scan # 或者使用更通用的方法 sudo partprobe然后使用lsblk或fdisk -l查看/dev/sda的总容量是否已经变大。第二步扩展包含 PV 的分区。关键点来了LVM 的物理卷PV是创建在磁盘分区如/dev/sda3上的而不是整个磁盘/dev/sda。所以你需要扩展的是那个承载着 PV 的分区。使用pvs或pvdisplay命令查看当前 PV 创建在哪个设备上。假设是/dev/sda3。使用fdisk或parted工具删除旧的分区/dev/sda3并创建一个新的、更大的分区。注意删除分区不会丢失其上的 LVM 数据因为 LVM 元数据在分区内部但操作仍需谨慎使用sudo fdisk /dev/sda。输入p打印分区表记住/dev/sda3的起始扇区Start。输入d然后输入分区号3删除它。输入n创建新分区选择主分区或逻辑分区和原来一致分区号必须还是 3。当询问起始扇区时输入刚才记下的原起始扇区这一点至关重要确保起始位置和原来完全一样。当询问结束扇区时直接回车使用所有可用空间。输入t更改分区类型选择分区3将其类型设置为8e(Linux LVM)。输入p确认新分区表确保/dev/sda3的起始扇区没变但结束扇区变大了。输入w写入并退出。重启系统或使用partprobe让内核重新加载分区表。有时重启是最稳妥的。第三步扩展物理卷PV本身。分区变大了但上面的 PV 还没变。使用pvresize命令告诉 LVM 这个 PV 的容量变了。sudo pvresize /dev/sda3运行pvdisplay /dev/sda3你会看到PV Size变大了并且多出了Free PE。至此卷组VG的“池子”里就有了新的空闲空间。现在你可以回到第3章使用lvextend和resize2fs来扩展你的逻辑卷了。4.2 途径二添加新硬盘并加入卷组假设你添加了一块新硬盘系统识别为/dev/sdb。第一步在新硬盘上创建物理卷PV。sudo pvcreate /dev/sdb如果系统提示设备/dev/sdb上可能有现有签名可以加上-f参数强制创建sudo pvcreate -f /dev/sdb。第二步将新的物理卷PV加入到现有的卷组VG中。sudo vgextend ubuntu-vg /dev/sdb现在运行vgdisplay ubuntu-vg你应该能看到VG Size变大了并且有了可观的Free Size。重大避坑提示关于设备名稳定性在物理服务器或某些虚拟化环境下磁盘设备名如/dev/sdb可能在重启后发生变化例如变成/dev/sdc。如果 LVM 仅通过设备名来识别 PV这会导致卷组无法激活进而导致系统无法启动。解决方案使用磁盘的稳定标识符如/dev/disk/by-id/或/dev/disk/by-uuid/来创建 PV。找到新硬盘的稳定路径ls -l /dev/disk/by-id/找到对应sdb的条目通常类似ata-VENDOR_MODEL_SERIAL或wwn-0x500xxxx。使用这个路径创建 PV 和扩展 VGsudo pvcreate /dev/disk/by-id/ata-VENDOR_MODEL_SERIAL sudo vgextend ubuntu-vg /dev/disk/by-id/ata-VENDOR_MODEL_SERIAL这样无论设备名怎么变LVM 都能通过唯一的 ID 找到它。这是我用一次惨痛的数据恢复经历换来的经验。完成以上任一途径后你的卷组就有了新的空闲空间。此时流程就回到了情况A。你可以按照第3章的步骤使用lvextend和resize2fs/xfs_growfs来最终扩展你的根逻辑卷。5. 扩容后的善后与进阶思考成功扩容并验证df -h显示空间充足后工作并没有完全结束。作为一个负责任的系统管理者我们还需要做一些善后工作并思考如何避免问题再次发生。5.1 验证与监控首先进行一次简单的写入测试确保新空间是可用的# 创建一个1GB的大文件测试写入 sudo dd if/dev/zero of/testfile bs1M count1024 # 检查文件是否创建成功 ls -lh /testfile # 删除测试文件 sudo rm /testfile其次建立监控。空间问题不应该等到 100% 才被发现。你可以配置告警 使用像PrometheusNode ExporterGrafana或Zabbix这样的监控系统对磁盘使用率设置告警阈值例如 85%。简易脚本 写一个简单的 Shell 脚本通过df或du定期检查并通过邮件或即时通讯工具发送报警。#!/bin/bash THRESHOLD90 USAGE$(df -h / | awk NR2 {print $5} | sed s/%//) if [ $USAGE -gt $THRESHOLD ]; then echo 警告根分区使用率 ${USAGE}% 超过阈值 ${THRESHOLD}% | mail -s 磁盘空间告警 adminexample.com fi然后将这个脚本加入crontab定时执行。5.2 根治空间消耗清理与规划扩容是“治标”清理和规划才是“治本”。回顾第2章我们找到的空间占用大户进行针对性清理清理 Docker Docker 是著名的“空间吞噬兽”。# 删除所有已停止的容器 docker container prune # 删除所有未被使用的镜像、容器卷和网络谨慎会删除悬空镜像 docker system prune -a # 更激进地清理所有构建缓存 docker builder prune考虑为 Docker 配置存储驱动选项或者将 Docker 的数据目录 (/var/lib/docker) 迁移到更大的独立分区。清理 APT 缓存sudo apt clean # 删除所有已下载的 .deb 包 sudo apt autoclean # 删除旧版本的 .deb 包 sudo apt autoremove # 删除自动安装且不再需要的依赖包管理日志检查/var/log目录下的大文件。使用journalctl清理系统日志# 只保留最近两天的日志 sudo journalctl --vacuum-time2d # 或者限制日志占用的最大磁盘空间 sudo journalctl --vacuum-size500M确保logrotate服务正常运行它负责自动轮转和压缩旧日志。查找并删除特定大文件# 查找大于100M的文件 sudo find / -type f -size 100M -exec ls -lh {} \; 2/dev/null | sort -k5,5hr5.3 架构层面的预防更好的分区方案对于新部署的系统为了避免根分区空间不足的窘境可以考虑更合理的分区方案独立分区 将/home、/var、/opt等容易增长的用户数据和应用程序目录单独分区。即使它们满了也不会影响根分区的系统运行。使用 LVM 并预留空间 在安装系统时就使用 LVM并为卷组VG分配比逻辑卷LV更多的空间。例如给一个 100G 的硬盘只给根逻辑卷分配 30G剩下的 70G 留在卷组池子里。这样未来扩容会非常灵活。云原生思路 对于容器化环境考虑使用宿主机的独立目录或网络存储如 NFS、Ceph来挂载容器的持久化数据完全避免容器日志和缓存挤占系统盘。5.4 关于“减容”的严肃警告在搜索热词里你可能会看到“lvm逻辑卷 扩容 减容”。这里我必须给出一个强烈警告对于根分区或者任何包含重要数据且已使用的逻辑卷在线缩小减容是极其危险的操作不推荐在生产环境尝试。虽然 LVM 理论上支持使用lvreduce缩小逻辑卷但这要求你先使用resize2fs仅限 ext2/3/4缩小文件系统。这个过程复杂容易出错并且任何一步失误都可能导致数据全部丢失。XFS 文件系统甚至根本不支持缩小。因此除非在测试环境或有绝对充分备份和回滚方案的情况下否则请将“减容”视为禁区。规划时保守一点多分配一些空间远比事后冒险缩容要安全得多。处理/dev/mapper/ubuntu--vg-ubuntu--lv空间不足的问题是一次典型的 Linux 系统运维实战。它考验的不仅是对命令的熟悉程度更是对存储架构物理磁盘 - 分区 - PV - VG - LV - 文件系统的清晰理解。从精准诊断、审慎操作到事后优化每一步都需要耐心和细心。希望这篇详细的指南能帮你不仅解决眼前的问题更能建立起一套应对此类问题的系统性方法论。记住在按下回车键执行任何可能影响数据的命令前多一次确认总好过事后的追悔莫及。
