凌晨收到告警：No space left on device，网站写日志失败。登上服务器 df -h 一看，根分区 100%。linux查看磁盘空间 命令不止 df 一个，配合 du 和 lsof 才能找到真正占地方的东西。

df -h 先看哪个分区满了

df -h 按可读单位列出各挂载点的容量、已用、可用和挂载点，Use% 到 100% 的那个就是元凶。df -i 看 inode，有时候容量还有富余，inode 先耗尽，表现一样是写不进去，小文件多的目录容易中招。两个都查一遍，别只盯容量。文件系统只读挂载时，df 也会显示异常，dmesg 里一般能看到磁盘错误。挂载点那一列能看出是根分区还是 /home，别看到数字就删文件。

df -h && df -i

du 逐层定位大目录

进到根目录，du -h --max-depth=1 / 2>/dev/null | sort -rh | head -20，列出第一层目录的大小并从大到小排。锁定目录后再往下钻一层，把 max-depth 改小。日志目录常是重灾区，/var/log 下几十 G 的日志很常见。du -sh 目录名 能快速看单个目录总量，-x 参数可以跳过其他挂载点，避免统计到挂载进来的磁盘。du 统计大目录耗时，可以先按修改时间筛最近的文件。删日志前先看文件名里的日期，压缩归档比直接删稳妥。

du -h --max-depth=1 /var 2>/dev/null | sort -rh | head

删了文件空间没释放

日志被 rm 了但 df 还是满的，多半是进程还拿着文件句柄。lsof | grep deleted 能看到这类文件，重启对应服务，或者用 > 重定向清空，空间才会回来。清正在写的日志优先用 truncate，不要直接 rm。删之前确认文件归属，别把数据库的 binlog 当成普通日志清了。

日常巡检就跑 df -h 和 df -i，容量异常再上 du 和 lsof。分区留 10% 余量，别等满了再处理，数据库写满一次修起来很麻烦。这几条 linux查看磁盘空间 命令存成笔记，下次登录直接抄。定时任务里加个磁盘检查脚本，超过 85% 发邮件，比等告警强。