半夜被根分区满了的告警叫起来登机器敲一把df -h看到/那一行 Use% 顶着 100%服务却还在正常跑再敲du -sh /统计出来只有 40G跟分区总容量差出一大截。这种数字对不上的场面我遇到过太多次后来才慢慢想明白df -h 读的是文件系统自己上报的统计信息而 du 是一层一层去数文件和目录两者天生就不是一个口径对不上账才是常态。df -h这条命令看着简单实际上它是排查磁盘类故障的第一个入口也是最容易被误读的一条命令。不管你是刚接手一台 Linux 服务器的新人还是天天跟虚拟机、容器打交道的老手看懂这七列数字背后的含义能省掉大量明明还有空间为什么写不进去为什么扩容了但 df 没变化的无用折腾。这篇就把我对df -h的理解拆开讲清楚每一列到底在说什么、什么时候它说的话会骗人、怎么从它的输出倒推出该做的动作另外也把桌面上那类磁盘空间不足的常见误报一起理一理。1. 先把 df -h 输出的那几列读明白df是 disk free 的缩写默认以 1K 块为单位输出加上-h之后换成人类好读的 G、M、T。很多人第一次用它扫一眼 Use% 就结束了其实那七列里每一列都有它的脾气。列名实际含义常见的误读点Filesystem设备节点或伪文件系统名出现 tmpfs、overlay、udev、/dev/loop 时并不是真实磁盘Size文件系统总容量-h是 1024 进制且做过取整不要拿它做精确计算Used已用空间包含日志、元数据、目录索引不只是你的文件Avail普通用户可用空间它不等于 Size 减 UsedUse%使用率分母是 Used 加 Avail不含保留块Mounted on挂载点同一块设备可能被挂到多个位置1.1 Size 减 Used 为什么不等于 Avail这是新手最容易卡住的第一个点。ext4 在格式化时默认会留出 5% 的空间给 root 专用目的是防止普通用户把盘写满之后系统关键进程日志、认证、数据库恢复连一点写缓冲都拿不到直接进入不可恢复的状态。举个实际数字一块 100G 的 ext4 数据盘Used 显示 50G你直觉上认为 Avail 应该是 50G但df -h给出的往往是 45G 左右中间那 5G 就是保留块。想确认这一点不用猜直接查超级块sudo tune2fs -l /dev/sda1 | grep -i reserved block count # Reserved block count: 1310720按 4K 块换算1310720 × 4K 正好是 5G跟df里消失的那部分对得上。这个差值在系统盘上通常是好事但在纯数据盘、大盘比如 2T 以上上就有点浪费了5% 意味着上百 G 被锁着。数据盘上我一般会把保留比例降到 1%sudo tune2fs -m 1 /dev/sdb1 df -h /data注意系统盘不建议把保留比例调到 0。保留块就是给系统留的那口气省这点空间换来的往往是故障时无法登录、日志写不动。1.2 Use% 到底是怎么算出来的df计算使用率的方式是Used ÷ (Used Avail)然后再向上取整。注意分母里没有保留块。所以会出现两个有意思的现象一是实际用了 99.4% 的时候它显示 100%二是当 Use% 已经是 100% 时root 用户仍然可能写得进去一点东西因为保留块还没用完。真正判断这个分区还撑不撑得住我建议看Avail的绝对值而不是Use%。一个 500G 的分区用到 92%剩下 40G比一个 20G 的分区用到 85%、下剩 3G安全得多。线上的报警规则里我通常写成Use% ≥ 85% 或者 Avail 5G满足任一即告警后者往往比前者更早发现问题尤其是小容量的/var、/boot分区。1.3 Filesystem 那一列冒出来的奇怪名字一台正常的 Ubuntu 服务器上敲df -h输出里往往混杂着一堆看不懂的家伙/dev/sda1、/dev/nvme0n1p2真实的本地设备前者是传统 SATA/SCSI 命名后者是 NVMe 的命名p2表示第二个分区。/dev/mapper/ubuntu--vg-ubuntu--lvLVM 逻辑卷名字里的--是-的转义代表卷组和逻辑卷的层级。overlay容器里的根文件系统它上报的容量其实是宿主机那块盘的容量所以在容器里看到总容量 500G别慌那不是分配给容器的额度。tmpfs、devtmpfs内存文件系统看着有容量实际吃的是内存。/dev/loop0到/dev/loopNsnap 打包的镜像挂载数量多的时候能刷半屏会严重干扰阅读。192.168.1.10:/dataNFS 挂载容量取决于服务端。被 loop 设备刷屏的时候加个排除参数就清爽了df -h -x squashfs -x tmpfs -x devtmpfs # 只看真实磁盘和类型 df -hT -x squashfs -x tmpfs -x devtmpfs-T会多出一列文件系统类型排查 ext4、xfs、nfs、cifs 混用的环境时特别有用。另外还有个小技巧df后面可以直接跟路径它会自动告诉你这个路径落在哪个文件系统上df -h /var/log/nginx/access.log # 输出里 Mounted on 那一列就是该文件所在的挂载点这个用法在某个目录到底属于哪块盘的问题上比对着mount输出一个个比对快得多。2. df 与 du 对不上账问题多半藏在这三个地方老手都知道一句话df看的是文件系统的账面数字du数的是目录树里的文件。账面大于目录树之和是绝大多数空间凭空消失故障的根因。下面这三种情况我按遇到频率从高到低排。2.1 文件被删除但句柄还被进程攥着这是线上最经典的一种。表现是df -h显示某个分区快满了du -sh一层层找下来却怎么也对不上大文件就是找不到。原因在于进程打开着一个很大的日志文件logrotate 或者运维同学把文件名删掉了或者 rename 后又清空失败但进程持有的文件描述符还指着那个 inode内核不敢回收这块空间于是文件在目录树里看不见了空间却实实在在占着。排查手段我有两个常用的# 方式一lsof 列出所有已删除但仍被占用的文件 sudo lsof L1 2/dev/null | head -20 # 方式二直接翻 proc不依赖 lsof 是否安装 sudo find /proc/*/fd -ls 2/dev/null | grep -i deleted | head -20输出里能看到进程名、PID 和文件大小。确认之后处理方式很直接——重启那个进程空间立刻释放sudo systemctl restart nginx sudo systemctl restart rsyslog我踩过的一次坑是一个 Java 服务自己写了滚动日志删除旧文件后没有重新打开文件句柄跑了两周把 40G 的数据盘吃满。当时第一反应是du找大文件找了半小时没有结果最后用lsof L1十秒定位。由此总结出的预防办法是logrotate 配置里如果进程不支持重新打开日志文件就加copytruncate或者写postrotate脚本触发进程 reload别让删了名字但没关句柄这种状态存在超过一轮。注意有资料教人用: /proc/PID/fd/N直接把句柄清空来释放空间这个操作会让文件偏移量错乱对于正在追加写的日志文件可能造成内容混乱风险环境里更稳妥的做法还是重启进程。2.2 目录被后来的挂载点盖住了第二种情况比较隐蔽/data目录本身在系统盘上里面已经写了 30G 数据之后有人把一块新盘挂到/data。挂载动作一完成原来那 30G 就被盖在下层了通过/data路径完全看不见但它的空间依然被系统盘占着也不会被du /data统计到。判断和检查的方法# 确认 /data 是不是一个独立挂载点底下的设备是谁 findmnt /data # 临时把根挂到别处去看被遮住的内容 sudo mkdir -p /mnt/rootview sudo mount --bind / /mnt/rootview sudo du -sh /mnt/rootview/data如果确认有数据被盖住正确姿势是先umount /data把老数据搬走或者删掉再重新挂载。这类问题多半出在自动化装机脚本里挂载顺序写反了也可能是容器场景下把宿主机目录挂进去恰好覆盖了镜像里已有的数据目录导致应用读不到配置文件。凡是挂载之后应用突然说找不到原来的文件优先怀疑这一条。2.3 权限、硬链接和文件系统特性带来的偏差即便没有前两种情况du的总和和df仍然会有差距这属于正常误差来源主要有三块权限不足导致漏算普通用户跑du时遇到没有读权限的目录会直接跳过并打印一行错误。所以定位空间问题时du一定要加sudo否则数字偏小会误导你往错误的方向查。硬链接只算一次du对同一个 inode 只计一次而块级的df是按实际占用算的。这种差异一般不大但如果系统里有大量硬链接备份比如 rsync 的--link-dest增量备份偏差就明显了。压缩和去重btrfs、zfs 开了透明压缩之后du报的是逻辑大小df报的是压缩后的物理占用差出几倍都可能。稀疏文件同理ls -l看是 10Gdu看可能只有几百 M。另外提醒一句跨挂载点做统计时务必加-x或者--one-file-system# 只看当前文件系统不跨进 /proc、/sys 和其它挂载点 sudo du -x -h --max-depth1 / | sort -h | tail -15不加-x的话du /会一路扫进/proc、/sys、/dev不仅慢还可能因为内核伪文件系统报出莫名其妙的数字甚至卡死。2.4 我固定用的对账顺序碰到空间不对账我现在基本按这个顺序走一般两三分钟能定位df -hT -x squashfs -x tmpfs—— 确认是哪块盘、什么文件系统、Use% 多少。df -i—— 先排除 inode 用满这个可能见下一节。sudo lsof L1—— 排除被删但仍占用的文件句柄。sudo du -x -h --max-depth1 /path | sort -h—— 层级定位从最可疑的挂载点往下钻。sudo find /path -xdev -type f -size 1G -printf %s %p\n 2/dev/null | sort -rn | head -20—— 捞出大文件。dmesg -T | tail -50—— 看看是不是文件系统已经报错甚至被重挂为只读。这六步覆盖了我遇到过的九成以上磁盘空间问题。顺序很重要先做便宜的检查前两步几乎是瞬时的再做昂贵的全盘扫描。3. 空间明明还剩很多却写不进去有那么几类故障df -h看上去一片祥和但应用就是报No space left on device。这种情况别急着怀疑df骗人多半是下面四种情况之一。3.1 inode 用光磁盘有空间却创建不了新文件ext4、xfs 这类文件系统在格式化时就把 inode 总数定死了每个文件包括目录、符号链接都要占用一个。如果某个目录里塞了几百万个小文件inode 先被耗尽这时候即便df -h显示只用了 30%任何创建新文件的操作照样失败。查看方式是df -idf -i / # Filesystem Inodes IUsed IFree IUse% Mounted on # /dev/sda1 6553600 6553401 199 100% /IUse% 到 100% 就是它了。接下来要找出是哪个目录在疯狂制造小文件。我常用的笨办法是按目录统计文件数量sudo find /var -xdev -type f -printf %h\n 2/dev/null | sort | uniq -c | sort -rn | head -20实际经验里制造 inode 压力的重灾区很固定邮件队列目录/var/spool/postfix/maildrop里一堆卡住的小邮件、PHP 的 session 文件目录、某些框架的缓存碎片、还有容器日志目录里成千上万个没轮转掉的小文件。清理的时候一定要用find ... -delete或者分批rm几百万文件直接rm -rf会把 IO 打满、rm进程本身也会很慢甚至触发磁盘百分百忙碌导致服务雪崩。提示清理 inode 之前先停掉正在往里写的服务否则一边删一边生永远清不完。3.2 保留块被吃掉之后普通用户就写不动了回到 1.1 说的保留块。ext4 那 5% 是留给 root 的如果一个服务的运行账号不是 root那么当df -h显示的 Avail 掉到 0 的时候它的写入就开始报错而此时用 root 去写还成功特别容易被误判成权限问题。df -h显示的 Avail 本身就已经扣掉了保留块所以看到 Avail 接近 0 就是真要出事了不用怀疑。至于用df判断到底是文件系统满了还是目录满了还有个细节如果连df -h都执行报错说明可能是文件系统元数据损坏需要进单用户模式跑fsck了。3.3 文件系统被重挂为只读磁盘出现 I/O 错误之后ext4 默认会做一件事把整个文件系统重新挂成只读防止错误扩散把损失控制在最小范围。这时候的表现很有迷惑性——df -h显示空间充足ls也正常但任何写操作都报Read-only file system。排查两个地方mount | grep ro, dmesg -T | grep -iE ext4|xfs|I/O error|remount | tail -30如果dmesg里出现了EXT4-fs error或者remounting filesystem read-only那说明底层块设备已经出问题了可能的原因包括云主机底层存储异常、磁盘寿命到期、虚拟机所在宿主机存储抖动。处理流程是立刻备份能读出来的数据然后对文件系统做检查修复必要时把盘换掉。这类问题千万别只盯着df数字正常不代表盘是健康的。3.4 tmpfs 和共享内存把内存吃掉了df -h输出里/run、/dev/shm、/tmp这几行经常是 tmpfs。它们的容量看起来挺大其实上限来自物理内存/dev/shm默认是物理内存的一半/run的上限通常是物理内存的 10% 左右不同发行版和 systemd 版本会有差异直接看df -h最准。往这些目录写大文件消耗的是内存和交换分区不是硬盘。数据库场景特别容易在这里翻车。有些数据库产品把共享内存段放在/dev/shm里如果这个目录容量不够启动就失败报错信息里还带着No space left on device让人误以为硬盘满了。检查方式是df -h -t tmpfs ipcs -m | head真遇到容量不足可以临时扩大sudo mount -o remount,size8G /dev/shm df -h /dev/shm但这只是一时之计内存是有限的把/dev/shm调大等于把风险转移给内存和 OOM Killer长远看还是得重新规划实例规格。4. 从 df 的输出倒推虚拟机磁盘满了该动哪一层df -h最有价值的用法之一是帮你判断扩容到底该扩哪一层。我见过太多次在虚拟机管理界面把虚盘从 20G 调到 100G重启进系统敲df -h容量纹丝不动然后就开始怀疑人生。4.1 先判断卡在磁盘、分区、还是文件系统一块盘从物理层到能被应用使用要经过虚拟磁盘 → 分区表 → LVM可选→ 文件系统这几层其中任何一层没跟上df都看不到新容量。判断方法就是拿lsblk和df -h对照着看现象卡在哪一层该做的事虚盘已经变大lsblk里磁盘总量还是旧的系统没识别到新容量触发 SCSI 重扫或者重启lsblk 磁盘变大了但分区还是原来的大小分区表没扩growpart 扩展分区分区变大了pvs显示卷组还是旧的LVM 物理卷没跟上pvresize卷组有余量但逻辑卷没变逻辑卷没扩lvextend逻辑卷变大了df 还是旧数字文件系统没扩resize2fs / xfs_growfs触发磁盘重扫的做法echo 1 | sudo tee /sys/class/block/sda/device/rescan lsblk有些存储驱动不支持在线重扫那就只能重启虚拟机重启前先确认业务可以中断。4.2 分区扩容growpart 加 resize2fs 两步走假设是/dev/sda根分区是第一个分区文件系统是 ext4sudo apt install -y cloud-guest-utils # growpart 由这个包提供 lsblk sudo growpart /dev/sda 1 # 把 sda1 撑到磁盘尾部 sudo resize2fs /dev/sda1 # ext4 支持在线扩容 df -h /growpart后面跟的是磁盘名和分区序号中间用空格分隔不要写成/dev/sda1这种设备全路径写错了它会报找不到。另外它只能扩展磁盘末尾的那个分区如果你的分区表里 sda1 后面还跟着一块 swap就会扩展失败需要先把 swap 挪走。ext4 的resize2fs可以在挂载状态下执行这点很方便但扩容前该做的准备不能省在虚拟机层面打一个快照或者至少确认重要数据有备份。分区表操作虽然成熟但一次意外断电、一次输入错误代价可能就是整个系统盘。4.3 LVM 场景多一步 pvresizeUbuntu Server 用 LVM 安装时有个历史习惯默认只把卷组的一部分空间分给根逻辑卷剩下的留在卷组里。很多人第一次扩容时发现分区已经撑满了磁盘df还是没变化原因就在这。# 1. 先确认物理卷识别到新容量 sudo pvresize /dev/sda3 sudo pvs # 2. 查看卷组剩余空间 sudo vgs # 3. 扩展逻辑卷把剩余空间全给它 sudo lvextend -l 100%FREE /dev/ubuntu-vg/ubuntu-lv # 4. 扩展文件系统 sudo resize2fs /dev/ubuntu-vg/ubuntu-lv # 5. 验证 df -h /如果只想扩固定的量而不是全部把-l 100%FREE换成-L 20G更合适。生产环境上我一般会留一点卷组余量方便以后做快照LVM 快照需要卷组里有未分配空间。4.4 XFS 的差别和扩容后的校验CentOS、RHEL 系或者装了 XFS 的系统第 4 步不是resize2fs而是xfs_growfssudo xfs_growfs /注意xfs_growfs后面跟的是挂载点不是设备名这点跟resize2fs正好相反很多人第一次用会踩坑。另外 XFS 不支持在线缩小只能扩不能缩规划容量时心里要有数。扩容完的校验别偷懒除了df -h还要看一眼 inode 有没有跟着增加df -h / df -i / df -h --totalext4 在线扩容会自动把 inode 表也扩上去XFS 动态分配 inode 根本不需要关心。如果发现df -h的 Size 涨了但df -i的 Inodes 没动说明扩容只完成了一半得回头看看是不是 lvextend 之后忘了 resize2fs。5. 桌面上的磁盘空间不足多半是另一回事前面讲的都是服务器视角。但日常被人问得最多的其实是桌面系统上弹出来的磁盘空间不足——这两类问题的排查思路差别很大混在一起想容易钻牛角尖。5.1 办公软件报空间不足先看默认保存位置在哪一个高频场景编辑文档时提示磁盘空间不足但一看系统盘还剩几十个 G。这里的关键在于很多办公软件的默认保存位置指向了云同步目录。同步盘的工作原理是本地保留一份副本、云端保留一份当你保存一个大文件时确实需要本地空间而且同步客户端自己的缓存目录往往也在系统盘的用户目录下会额外占用一份。排查顺序我一般这么走打开此电脑看系统盘通常是 C 盘的剩余空间别只看总容量。检查云同步客户端的本地缓存目录大小这类目录通常藏在用户目录下面的隐藏文件夹里动辄几十 G。检查系统临时目录用%TEMP%在资源管理器地址栏里直接回车就能跳过去。办公软件保存大文件时会先写临时文件通常需要原文件两三倍的空间。如果文档本身很大比如几十 M 的演示文稿、带大量嵌入对象的表格建议先另存为到本地非同步目录处理完再放回去。治本的办法是在办公软件的选项里把默认保存位置从同步目录改成纯本地目录同步这件事交给自己手动控制。5.2 有内存但提示磁盘空间不足是把两个东西搞混了内存和硬盘空间是两个完全不同的东西内存是运行时的临时工作区断电就没了硬盘是持久存储。程序报磁盘空间不足就是硬盘的事跟内存条插了几根无关。反过来程序报内存不足时也可能是页面文件虚拟内存所在的那块盘满了导致系统没法把内存里的数据换出去。所以排查路径是这样的任务管理器的性能页看一眼内存占用和磁盘占用这两个指标在同一屏能对上。再打开此电脑看每个盘的剩余空间。如果系统盘紧张、并且页面文件设置在那块盘上把页面文件挪到空间充裕的盘或者清理系统盘。我自己的习惯是系统盘永远留出 15% 到 20% 的空闲。低于这个比例之后系统更新、休眠文件、临时文件都会开始互相挤表现出来就是各种莫名其妙的报错。5.3 图形界面不显示剩余容量时的命令行兜底df -h在 Linux 上是标配Windows 上其实也有对应的东西只是藏得深一点。如果资源管理器里看不到驱动器容量可能是视图设置问题也可能是盘符没分配# PowerShell Get-PSDrive -PSProvider FileSystem Get-Volume | Select-Object DriveLetter, FileSystemLabel, SizeRemaining, Size:: 传统命令行 wmic logicaldisk get caption,size,freespace,filesystem如果某块盘在磁盘管理里能看到、但在此电脑里没有盘符那就是没分配驱动器号去磁盘管理里补一个就行。至于网络映射的驱动器本来就不一定显示容量条用上面两条命令能直接读到服务端返回的数字。顺带说一句Linux 下的df -h、Windows 下的wmic logicaldisk、macOS 下的df -h本质是同一件事的三种外壳掌握一个之后换个系统也就是换个名字的事。6. 日常巡检里我固定跑的几条命令组合最后说说我平时怎么把df用成一套轻量监控而不是等告警来了才临时敲一把。6.1 一条命令筛出高占用挂载点-P参数的作用是强制单行输出避免长设备名把一行折断成两行导致列错位配合awk做筛选非常稳# 使用率 80% 以上的挂载点 df -hP -x tmpfs -x devtmpfs -x squashfs | awk NR1 $50 80 {print $6 已用 $5 可用 $4} # inode 使用率 70% 以上 df -iP | awk NR1 $50 70 {print $6 inode 已用 $5}$50这个写法是为了把85%这种带百分号的字符串强制转成数字来比较直接写$5 80在某些 awk 实现里会退化成字符串比较结果完全不对这个坑我在脚本里踩过一次。6.2 定时留快照做趋势观察单次采集只能看到当下看不出增长速度。我习惯每天留一条记录格式固定方便以后用命令行对比# 加入日常任务每天凌晨记录一次 ( date %F %T; df -hP -x tmpfs -x devtmpfs -x squashfs ) /var/log/disk-snapshot.log日志本身也要做轮转不然监控日志自己把盘写满就太讽刺了。需要看趋势的时候直接翻历史记录对比 Size 和 Avail一个分区是突然涨上去还是每天缓慢涨 1%处理方式完全不同前者查句柄和大文件后者多半是日志没轮转或者数据只进不出。6.3 阈值设多少合适阈值没有标准答案但有经验值可以参考对象提醒线处理线说明系统盘 /80%85%系统盘要留给日志、更新、临时文件数据盘85%90%数据库场景要额外考虑 WAL、备份落盘inode70%85%小文件多的场景要单独盯可用绝对空间10G5G低于这个数即使百分比不高也要处理有了阈值动作也要提前定好别等报警了才开始查。我的习惯是提醒线一到先跑一次 6.1 的命令定位到具体目录把大文件和异常增长点记下来处理线一到直接启动清理或者扩容流程不等业务受影响。还有一条容易忽略的经验别把du塞进高频定时任务。df读的是文件系统统计毫秒级返回几分钟跑一次毫无压力du要遍历整个目录树在千万级小文件或者网络存储上能跑十几分钟还可能把磁盘 IO 拖满。真要定期做容量分析放在业务低峰期并且加-x限制在单个文件系统内。
半夜被根分区满了的告警叫起来登机器敲一把df -h看到/那一行 Use% 顶着 100%服务却还在正常跑再敲du -sh /统计出来只有 40G跟分区总容量差出一大截。这种数字对不上的场面我遇到过太多次后来才慢慢想明白df -h 读的是文件系统自己上报的统计信息而 du 是一层一层去数文件和目录两者天生就不是一个口径对不上账才是常态。df -h这条命令看着简单实际上它是排查磁盘类故障的第一个入口也是最容易被误读的一条命令。不管你是刚接手一台 Linux 服务器的新人还是天天跟虚拟机、容器打交道的老手看懂这七列数字背后的含义能省掉大量明明还有空间为什么写不进去为什么扩容了但 df 没变化的无用折腾。这篇就把我对df -h的理解拆开讲清楚每一列到底在说什么、什么时候它说的话会骗人、怎么从它的输出倒推出该做的动作另外也把桌面上那类磁盘空间不足的常见误报一起理一理。1. 先把 df -h 输出的那几列读明白df是 disk free 的缩写默认以 1K 块为单位输出加上-h之后换成人类好读的 G、M、T。很多人第一次用它扫一眼 Use% 就结束了其实那七列里每一列都有它的脾气。列名实际含义常见的误读点Filesystem设备节点或伪文件系统名出现 tmpfs、overlay、udev、/dev/loop 时并不是真实磁盘Size文件系统总容量-h是 1024 进制且做过取整不要拿它做精确计算Used已用空间包含日志、元数据、目录索引不只是你的文件Avail普通用户可用空间它不等于 Size 减 UsedUse%使用率分母是 Used 加 Avail不含保留块Mounted on挂载点同一块设备可能被挂到多个位置1.1 Size 减 Used 为什么不等于 Avail这是新手最容易卡住的第一个点。ext4 在格式化时默认会留出 5% 的空间给 root 专用目的是防止普通用户把盘写满之后系统关键进程日志、认证、数据库恢复连一点写缓冲都拿不到直接进入不可恢复的状态。举个实际数字一块 100G 的 ext4 数据盘Used 显示 50G你直觉上认为 Avail 应该是 50G但df -h给出的往往是 45G 左右中间那 5G 就是保留块。想确认这一点不用猜直接查超级块sudo tune2fs -l /dev/sda1 | grep -i reserved block count # Reserved block count: 1310720按 4K 块换算1310720 × 4K 正好是 5G跟df里消失的那部分对得上。这个差值在系统盘上通常是好事但在纯数据盘、大盘比如 2T 以上上就有点浪费了5% 意味着上百 G 被锁着。数据盘上我一般会把保留比例降到 1%sudo tune2fs -m 1 /dev/sdb1 df -h /data注意系统盘不建议把保留比例调到 0。保留块就是给系统留的那口气省这点空间换来的往往是故障时无法登录、日志写不动。1.2 Use% 到底是怎么算出来的df计算使用率的方式是Used ÷ (Used Avail)然后再向上取整。注意分母里没有保留块。所以会出现两个有意思的现象一是实际用了 99.4% 的时候它显示 100%二是当 Use% 已经是 100% 时root 用户仍然可能写得进去一点东西因为保留块还没用完。真正判断这个分区还撑不撑得住我建议看Avail的绝对值而不是Use%。一个 500G 的分区用到 92%剩下 40G比一个 20G 的分区用到 85%、下剩 3G安全得多。线上的报警规则里我通常写成Use% ≥ 85% 或者 Avail 5G满足任一即告警后者往往比前者更早发现问题尤其是小容量的/var、/boot分区。1.3 Filesystem 那一列冒出来的奇怪名字一台正常的 Ubuntu 服务器上敲df -h输出里往往混杂着一堆看不懂的家伙/dev/sda1、/dev/nvme0n1p2真实的本地设备前者是传统 SATA/SCSI 命名后者是 NVMe 的命名p2表示第二个分区。/dev/mapper/ubuntu--vg-ubuntu--lvLVM 逻辑卷名字里的--是-的转义代表卷组和逻辑卷的层级。overlay容器里的根文件系统它上报的容量其实是宿主机那块盘的容量所以在容器里看到总容量 500G别慌那不是分配给容器的额度。tmpfs、devtmpfs内存文件系统看着有容量实际吃的是内存。/dev/loop0到/dev/loopNsnap 打包的镜像挂载数量多的时候能刷半屏会严重干扰阅读。192.168.1.10:/dataNFS 挂载容量取决于服务端。被 loop 设备刷屏的时候加个排除参数就清爽了df -h -x squashfs -x tmpfs -x devtmpfs # 只看真实磁盘和类型 df -hT -x squashfs -x tmpfs -x devtmpfs-T会多出一列文件系统类型排查 ext4、xfs、nfs、cifs 混用的环境时特别有用。另外还有个小技巧df后面可以直接跟路径它会自动告诉你这个路径落在哪个文件系统上df -h /var/log/nginx/access.log # 输出里 Mounted on 那一列就是该文件所在的挂载点这个用法在某个目录到底属于哪块盘的问题上比对着mount输出一个个比对快得多。2. df 与 du 对不上账问题多半藏在这三个地方老手都知道一句话df看的是文件系统的账面数字du数的是目录树里的文件。账面大于目录树之和是绝大多数空间凭空消失故障的根因。下面这三种情况我按遇到频率从高到低排。2.1 文件被删除但句柄还被进程攥着这是线上最经典的一种。表现是df -h显示某个分区快满了du -sh一层层找下来却怎么也对不上大文件就是找不到。原因在于进程打开着一个很大的日志文件logrotate 或者运维同学把文件名删掉了或者 rename 后又清空失败但进程持有的文件描述符还指着那个 inode内核不敢回收这块空间于是文件在目录树里看不见了空间却实实在在占着。排查手段我有两个常用的# 方式一lsof 列出所有已删除但仍被占用的文件 sudo lsof L1 2/dev/null | head -20 # 方式二直接翻 proc不依赖 lsof 是否安装 sudo find /proc/*/fd -ls 2/dev/null | grep -i deleted | head -20输出里能看到进程名、PID 和文件大小。确认之后处理方式很直接——重启那个进程空间立刻释放sudo systemctl restart nginx sudo systemctl restart rsyslog我踩过的一次坑是一个 Java 服务自己写了滚动日志删除旧文件后没有重新打开文件句柄跑了两周把 40G 的数据盘吃满。当时第一反应是du找大文件找了半小时没有结果最后用lsof L1十秒定位。由此总结出的预防办法是logrotate 配置里如果进程不支持重新打开日志文件就加copytruncate或者写postrotate脚本触发进程 reload别让删了名字但没关句柄这种状态存在超过一轮。注意有资料教人用: /proc/PID/fd/N直接把句柄清空来释放空间这个操作会让文件偏移量错乱对于正在追加写的日志文件可能造成内容混乱风险环境里更稳妥的做法还是重启进程。2.2 目录被后来的挂载点盖住了第二种情况比较隐蔽/data目录本身在系统盘上里面已经写了 30G 数据之后有人把一块新盘挂到/data。挂载动作一完成原来那 30G 就被盖在下层了通过/data路径完全看不见但它的空间依然被系统盘占着也不会被du /data统计到。判断和检查的方法# 确认 /data 是不是一个独立挂载点底下的设备是谁 findmnt /data # 临时把根挂到别处去看被遮住的内容 sudo mkdir -p /mnt/rootview sudo mount --bind / /mnt/rootview sudo du -sh /mnt/rootview/data如果确认有数据被盖住正确姿势是先umount /data把老数据搬走或者删掉再重新挂载。这类问题多半出在自动化装机脚本里挂载顺序写反了也可能是容器场景下把宿主机目录挂进去恰好覆盖了镜像里已有的数据目录导致应用读不到配置文件。凡是挂载之后应用突然说找不到原来的文件优先怀疑这一条。2.3 权限、硬链接和文件系统特性带来的偏差即便没有前两种情况du的总和和df仍然会有差距这属于正常误差来源主要有三块权限不足导致漏算普通用户跑du时遇到没有读权限的目录会直接跳过并打印一行错误。所以定位空间问题时du一定要加sudo否则数字偏小会误导你往错误的方向查。硬链接只算一次du对同一个 inode 只计一次而块级的df是按实际占用算的。这种差异一般不大但如果系统里有大量硬链接备份比如 rsync 的--link-dest增量备份偏差就明显了。压缩和去重btrfs、zfs 开了透明压缩之后du报的是逻辑大小df报的是压缩后的物理占用差出几倍都可能。稀疏文件同理ls -l看是 10Gdu看可能只有几百 M。另外提醒一句跨挂载点做统计时务必加-x或者--one-file-system# 只看当前文件系统不跨进 /proc、/sys 和其它挂载点 sudo du -x -h --max-depth1 / | sort -h | tail -15不加-x的话du /会一路扫进/proc、/sys、/dev不仅慢还可能因为内核伪文件系统报出莫名其妙的数字甚至卡死。2.4 我固定用的对账顺序碰到空间不对账我现在基本按这个顺序走一般两三分钟能定位df -hT -x squashfs -x tmpfs—— 确认是哪块盘、什么文件系统、Use% 多少。df -i—— 先排除 inode 用满这个可能见下一节。sudo lsof L1—— 排除被删但仍占用的文件句柄。sudo du -x -h --max-depth1 /path | sort -h—— 层级定位从最可疑的挂载点往下钻。sudo find /path -xdev -type f -size 1G -printf %s %p\n 2/dev/null | sort -rn | head -20—— 捞出大文件。dmesg -T | tail -50—— 看看是不是文件系统已经报错甚至被重挂为只读。这六步覆盖了我遇到过的九成以上磁盘空间问题。顺序很重要先做便宜的检查前两步几乎是瞬时的再做昂贵的全盘扫描。3. 空间明明还剩很多却写不进去有那么几类故障df -h看上去一片祥和但应用就是报No space left on device。这种情况别急着怀疑df骗人多半是下面四种情况之一。3.1 inode 用光磁盘有空间却创建不了新文件ext4、xfs 这类文件系统在格式化时就把 inode 总数定死了每个文件包括目录、符号链接都要占用一个。如果某个目录里塞了几百万个小文件inode 先被耗尽这时候即便df -h显示只用了 30%任何创建新文件的操作照样失败。查看方式是df -idf -i / # Filesystem Inodes IUsed IFree IUse% Mounted on # /dev/sda1 6553600 6553401 199 100% /IUse% 到 100% 就是它了。接下来要找出是哪个目录在疯狂制造小文件。我常用的笨办法是按目录统计文件数量sudo find /var -xdev -type f -printf %h\n 2/dev/null | sort | uniq -c | sort -rn | head -20实际经验里制造 inode 压力的重灾区很固定邮件队列目录/var/spool/postfix/maildrop里一堆卡住的小邮件、PHP 的 session 文件目录、某些框架的缓存碎片、还有容器日志目录里成千上万个没轮转掉的小文件。清理的时候一定要用find ... -delete或者分批rm几百万文件直接rm -rf会把 IO 打满、rm进程本身也会很慢甚至触发磁盘百分百忙碌导致服务雪崩。提示清理 inode 之前先停掉正在往里写的服务否则一边删一边生永远清不完。3.2 保留块被吃掉之后普通用户就写不动了回到 1.1 说的保留块。ext4 那 5% 是留给 root 的如果一个服务的运行账号不是 root那么当df -h显示的 Avail 掉到 0 的时候它的写入就开始报错而此时用 root 去写还成功特别容易被误判成权限问题。df -h显示的 Avail 本身就已经扣掉了保留块所以看到 Avail 接近 0 就是真要出事了不用怀疑。至于用df判断到底是文件系统满了还是目录满了还有个细节如果连df -h都执行报错说明可能是文件系统元数据损坏需要进单用户模式跑fsck了。3.3 文件系统被重挂为只读磁盘出现 I/O 错误之后ext4 默认会做一件事把整个文件系统重新挂成只读防止错误扩散把损失控制在最小范围。这时候的表现很有迷惑性——df -h显示空间充足ls也正常但任何写操作都报Read-only file system。排查两个地方mount | grep ro, dmesg -T | grep -iE ext4|xfs|I/O error|remount | tail -30如果dmesg里出现了EXT4-fs error或者remounting filesystem read-only那说明底层块设备已经出问题了可能的原因包括云主机底层存储异常、磁盘寿命到期、虚拟机所在宿主机存储抖动。处理流程是立刻备份能读出来的数据然后对文件系统做检查修复必要时把盘换掉。这类问题千万别只盯着df数字正常不代表盘是健康的。3.4 tmpfs 和共享内存把内存吃掉了df -h输出里/run、/dev/shm、/tmp这几行经常是 tmpfs。它们的容量看起来挺大其实上限来自物理内存/dev/shm默认是物理内存的一半/run的上限通常是物理内存的 10% 左右不同发行版和 systemd 版本会有差异直接看df -h最准。往这些目录写大文件消耗的是内存和交换分区不是硬盘。数据库场景特别容易在这里翻车。有些数据库产品把共享内存段放在/dev/shm里如果这个目录容量不够启动就失败报错信息里还带着No space left on device让人误以为硬盘满了。检查方式是df -h -t tmpfs ipcs -m | head真遇到容量不足可以临时扩大sudo mount -o remount,size8G /dev/shm df -h /dev/shm但这只是一时之计内存是有限的把/dev/shm调大等于把风险转移给内存和 OOM Killer长远看还是得重新规划实例规格。4. 从 df 的输出倒推虚拟机磁盘满了该动哪一层df -h最有价值的用法之一是帮你判断扩容到底该扩哪一层。我见过太多次在虚拟机管理界面把虚盘从 20G 调到 100G重启进系统敲df -h容量纹丝不动然后就开始怀疑人生。4.1 先判断卡在磁盘、分区、还是文件系统一块盘从物理层到能被应用使用要经过虚拟磁盘 → 分区表 → LVM可选→ 文件系统这几层其中任何一层没跟上df都看不到新容量。判断方法就是拿lsblk和df -h对照着看现象卡在哪一层该做的事虚盘已经变大lsblk里磁盘总量还是旧的系统没识别到新容量触发 SCSI 重扫或者重启lsblk 磁盘变大了但分区还是原来的大小分区表没扩growpart 扩展分区分区变大了pvs显示卷组还是旧的LVM 物理卷没跟上pvresize卷组有余量但逻辑卷没变逻辑卷没扩lvextend逻辑卷变大了df 还是旧数字文件系统没扩resize2fs / xfs_growfs触发磁盘重扫的做法echo 1 | sudo tee /sys/class/block/sda/device/rescan lsblk有些存储驱动不支持在线重扫那就只能重启虚拟机重启前先确认业务可以中断。4.2 分区扩容growpart 加 resize2fs 两步走假设是/dev/sda根分区是第一个分区文件系统是 ext4sudo apt install -y cloud-guest-utils # growpart 由这个包提供 lsblk sudo growpart /dev/sda 1 # 把 sda1 撑到磁盘尾部 sudo resize2fs /dev/sda1 # ext4 支持在线扩容 df -h /growpart后面跟的是磁盘名和分区序号中间用空格分隔不要写成/dev/sda1这种设备全路径写错了它会报找不到。另外它只能扩展磁盘末尾的那个分区如果你的分区表里 sda1 后面还跟着一块 swap就会扩展失败需要先把 swap 挪走。ext4 的resize2fs可以在挂载状态下执行这点很方便但扩容前该做的准备不能省在虚拟机层面打一个快照或者至少确认重要数据有备份。分区表操作虽然成熟但一次意外断电、一次输入错误代价可能就是整个系统盘。4.3 LVM 场景多一步 pvresizeUbuntu Server 用 LVM 安装时有个历史习惯默认只把卷组的一部分空间分给根逻辑卷剩下的留在卷组里。很多人第一次扩容时发现分区已经撑满了磁盘df还是没变化原因就在这。# 1. 先确认物理卷识别到新容量 sudo pvresize /dev/sda3 sudo pvs # 2. 查看卷组剩余空间 sudo vgs # 3. 扩展逻辑卷把剩余空间全给它 sudo lvextend -l 100%FREE /dev/ubuntu-vg/ubuntu-lv # 4. 扩展文件系统 sudo resize2fs /dev/ubuntu-vg/ubuntu-lv # 5. 验证 df -h /如果只想扩固定的量而不是全部把-l 100%FREE换成-L 20G更合适。生产环境上我一般会留一点卷组余量方便以后做快照LVM 快照需要卷组里有未分配空间。4.4 XFS 的差别和扩容后的校验CentOS、RHEL 系或者装了 XFS 的系统第 4 步不是resize2fs而是xfs_growfssudo xfs_growfs /注意xfs_growfs后面跟的是挂载点不是设备名这点跟resize2fs正好相反很多人第一次用会踩坑。另外 XFS 不支持在线缩小只能扩不能缩规划容量时心里要有数。扩容完的校验别偷懒除了df -h还要看一眼 inode 有没有跟着增加df -h / df -i / df -h --totalext4 在线扩容会自动把 inode 表也扩上去XFS 动态分配 inode 根本不需要关心。如果发现df -h的 Size 涨了但df -i的 Inodes 没动说明扩容只完成了一半得回头看看是不是 lvextend 之后忘了 resize2fs。5. 桌面上的磁盘空间不足多半是另一回事前面讲的都是服务器视角。但日常被人问得最多的其实是桌面系统上弹出来的磁盘空间不足——这两类问题的排查思路差别很大混在一起想容易钻牛角尖。5.1 办公软件报空间不足先看默认保存位置在哪一个高频场景编辑文档时提示磁盘空间不足但一看系统盘还剩几十个 G。这里的关键在于很多办公软件的默认保存位置指向了云同步目录。同步盘的工作原理是本地保留一份副本、云端保留一份当你保存一个大文件时确实需要本地空间而且同步客户端自己的缓存目录往往也在系统盘的用户目录下会额外占用一份。排查顺序我一般这么走打开此电脑看系统盘通常是 C 盘的剩余空间别只看总容量。检查云同步客户端的本地缓存目录大小这类目录通常藏在用户目录下面的隐藏文件夹里动辄几十 G。检查系统临时目录用%TEMP%在资源管理器地址栏里直接回车就能跳过去。办公软件保存大文件时会先写临时文件通常需要原文件两三倍的空间。如果文档本身很大比如几十 M 的演示文稿、带大量嵌入对象的表格建议先另存为到本地非同步目录处理完再放回去。治本的办法是在办公软件的选项里把默认保存位置从同步目录改成纯本地目录同步这件事交给自己手动控制。5.2 有内存但提示磁盘空间不足是把两个东西搞混了内存和硬盘空间是两个完全不同的东西内存是运行时的临时工作区断电就没了硬盘是持久存储。程序报磁盘空间不足就是硬盘的事跟内存条插了几根无关。反过来程序报内存不足时也可能是页面文件虚拟内存所在的那块盘满了导致系统没法把内存里的数据换出去。所以排查路径是这样的任务管理器的性能页看一眼内存占用和磁盘占用这两个指标在同一屏能对上。再打开此电脑看每个盘的剩余空间。如果系统盘紧张、并且页面文件设置在那块盘上把页面文件挪到空间充裕的盘或者清理系统盘。我自己的习惯是系统盘永远留出 15% 到 20% 的空闲。低于这个比例之后系统更新、休眠文件、临时文件都会开始互相挤表现出来就是各种莫名其妙的报错。5.3 图形界面不显示剩余容量时的命令行兜底df -h在 Linux 上是标配Windows 上其实也有对应的东西只是藏得深一点。如果资源管理器里看不到驱动器容量可能是视图设置问题也可能是盘符没分配# PowerShell Get-PSDrive -PSProvider FileSystem Get-Volume | Select-Object DriveLetter, FileSystemLabel, SizeRemaining, Size:: 传统命令行 wmic logicaldisk get caption,size,freespace,filesystem如果某块盘在磁盘管理里能看到、但在此电脑里没有盘符那就是没分配驱动器号去磁盘管理里补一个就行。至于网络映射的驱动器本来就不一定显示容量条用上面两条命令能直接读到服务端返回的数字。顺带说一句Linux 下的df -h、Windows 下的wmic logicaldisk、macOS 下的df -h本质是同一件事的三种外壳掌握一个之后换个系统也就是换个名字的事。6. 日常巡检里我固定跑的几条命令组合最后说说我平时怎么把df用成一套轻量监控而不是等告警来了才临时敲一把。6.1 一条命令筛出高占用挂载点-P参数的作用是强制单行输出避免长设备名把一行折断成两行导致列错位配合awk做筛选非常稳# 使用率 80% 以上的挂载点 df -hP -x tmpfs -x devtmpfs -x squashfs | awk NR1 $50 80 {print $6 已用 $5 可用 $4} # inode 使用率 70% 以上 df -iP | awk NR1 $50 70 {print $6 inode 已用 $5}$50这个写法是为了把85%这种带百分号的字符串强制转成数字来比较直接写$5 80在某些 awk 实现里会退化成字符串比较结果完全不对这个坑我在脚本里踩过一次。6.2 定时留快照做趋势观察单次采集只能看到当下看不出增长速度。我习惯每天留一条记录格式固定方便以后用命令行对比# 加入日常任务每天凌晨记录一次 ( date %F %T; df -hP -x tmpfs -x devtmpfs -x squashfs ) /var/log/disk-snapshot.log日志本身也要做轮转不然监控日志自己把盘写满就太讽刺了。需要看趋势的时候直接翻历史记录对比 Size 和 Avail一个分区是突然涨上去还是每天缓慢涨 1%处理方式完全不同前者查句柄和大文件后者多半是日志没轮转或者数据只进不出。6.3 阈值设多少合适阈值没有标准答案但有经验值可以参考对象提醒线处理线说明系统盘 /80%85%系统盘要留给日志、更新、临时文件数据盘85%90%数据库场景要额外考虑 WAL、备份落盘inode70%85%小文件多的场景要单独盯可用绝对空间10G5G低于这个数即使百分比不高也要处理有了阈值动作也要提前定好别等报警了才开始查。我的习惯是提醒线一到先跑一次 6.1 的命令定位到具体目录把大文件和异常增长点记下来处理线一到直接启动清理或者扩容流程不等业务受影响。还有一条容易忽略的经验别把du塞进高频定时任务。df读的是文件系统统计毫秒级返回几分钟跑一次毫无压力du要遍历整个目录树在千万级小文件或者网络存储上能跑十几分钟还可能把磁盘 IO 拖满。真要定期做容量分析放在业务低峰期并且加-x限制在单个文件系统内。
