1. 问题现象与初步诊断no space left on device这个错误提示对于Linux系统管理员来说再熟悉不过了。当我在凌晨三点收到服务器告警短信时这个错误意味着某个关键分区已经耗尽了所有可用空间。这种状况如果不及时处理轻则导致应用无法写入新数据重则可能引发系统崩溃。首先需要确认的是磁盘空间的真实使用情况。我通常会使用组合命令来全面检查df -hT # 查看各挂载点空间使用情况 df -i # 检查inode使用情况(有时空间足够但inode耗尽也会报错) lsblk # 查看磁盘分区结构最近一次排查中我发现一个典型案例/var分区显示使用率100%但通过du -sh /var计算实际内容大小却只有分区容量的70%。这种差异往往是由于被删除但仍被进程占用的文件导致的即deleted状态文件。2. 空间占用深度分析2.1 查找大文件与目录使用ncdu工具可以交互式分析磁盘使用情况ncdu / # 从根目录开始分析如果没有ncdu可以用传统命令组合du -h --max-depth1 / | sort -hr # 查看根目录下各子目录大小 find / -type f -size 1G -exec ls -lh {} # 查找大于1G的文件2.2 特殊文件类型处理某些文件类型需要特别注意日志文件/var/log/journal/ 下的系统日志可能占用大量空间Docker容器/var/lib/docker/overlay2/ 可能积累无用镜像层临时文件/tmp 和 /var/tmp 目录常被忽视核心转储/var/lib/systemd/coredump/ 可能保存大量崩溃记录2.3 已删除但未释放的空间当df显示空间不足但du计算正常时通常是有进程持有已删除的文件lsof L1 | grep deleted # 查看被删除但仍被占用的文件这种情况需要重启相关进程或服务才能释放空间。3. 空间释放实战方案3.1 日志文件清理对于系统日志不要简单使用rm删除而应该用日志轮替工具journalctl --vacuum-size200M # 保留最近200MB日志 find /var/log -type f -name *.log -exec truncate -s 0 {} \; # 清空日志内容3.2 软件包清理不同发行版的清理命令# Ubuntu/Debian apt autoremove apt clean # CentOS/RHEL yum clean all dnf autoremove # Alpine apk cache clean3.3 Docker系统清理docker system prune -af # 清理所有无用对象 docker volume prune # 清理未使用的卷3.4 特殊场景处理数据库表空间回收-- PostgreSQL VACUUM FULL ANALYZE; -- MySQL OPTIMIZE TABLE table_name;Git仓库清理git gc --prunenow --aggressive4. 预防与监控策略4.1 自动化清理脚本示例#!/bin/bash # 磁盘空间监控脚本 THRESHOLD90 PARTITION/var usage$(df --outputpcent $PARTITION | tail -1 | tr -d % ) if [ $usage -ge $THRESHOLD ]; then echo WARNING: $PARTITION usage $usage% exceeds threshold $THRESHOLD% # 执行清理操作 journalctl --vacuum-size200M apt clean fi4.2 监控工具推荐Prometheus Grafana配置node_exporter监控磁盘指标logrotate配置合理的日志轮替策略cron定时任务定期执行清理脚本4.3 文件系统选择建议对于频繁写入的场景建议使用XFS代替ext4更好的大文件处理性能为/var等重要目录单独分区考虑使用LVM实现动态扩容5. 高级故障排查当常规方法无法解决问题时可能需要检查是否是inode耗尽df -i检查是否有隐藏的挂载点mount | grep -v proc | grep -v sys检查是否有僵尸进程占用空间ps aux | grep defunct检查是否有恶意进程疯狂写磁盘iotop -oP6. 扩容方案选择当清理无法满足需求时考虑扩容云环境AWS EBS/Google Persistent Disk在线扩容阿里云云盘扩容物理服务器添加新硬盘并通过LVM扩容使用网络存储(NAS/SAN)容器环境调整PVC容量使用emptyDir定期清理策略7. 经验总结与常见误区不要直接删除正在使用的日志文件应该用truncate或echo file清空内容注意容器环境的特殊行为Kubernetes中的临时存储可能比想象的消耗更快数据库的auto vacuum配置不当配置可能导致表膨胀监控不仅要看空间使用率还要关注增长速度预测慎用rm -rf特别是在压力大的时候可能引发IO雪崩最后分享一个真实案例某次生产环境报警显示磁盘将满但常规清理无效。最终发现是某个微服务配置错误持续生成调试日志每小时产生10GB数据。通过lsof找到相关进程后修正配置并重启服务解决了问题。这提醒我们磁盘空间问题往往只是表象找到根本原因才能彻底解决。