Linux磁盘空间管理：df与du命令实战解析

1. Linux磁盘空间管理基础认知当你在终端敲下命令时突然看到No space left on device的红色警告那种感觉就像开车时油表突然亮起红灯。作为Linux系统管理员磁盘空间管理是最基础的生存技能之一。不同于Windows系统的图形化显示Linux需要掌握一系列命令行工具才能准确诊断空间问题。1.1 磁盘空间监控双雄df与dudfdisk filesystem是系统级的空间侦察兵它能快速扫描所有挂载点。我最常用的组合是df -hT这里的-h参数让输出以人类可读的单位显示GB/MB而-T会显示文件系统类型。典型输出如下Filesystem Type Size Used Avail Use% Mounted on /dev/sda1 ext4 50G 47G 1.2G 98% / tmpfs tmpfs 3.9G 0 3.9G 0% /dev/shm当Use%超过90%时就需要警惕了。不过要注意某些特殊文件系统如tmpfs显示的使用量可能包含内存缓存实际空间占用需要结合du验证。dudisk usage则是文件级的空间侦探。我最推荐的方式是du -h --max-depth1 / | sort -h这个命令会以MB/GB为单位显示根目录下所有一级子目录的大小并按人类可读格式排序。--max-depth1控制扫描深度对于大型目录可以显著减少扫描时间。警告在业务高峰期谨慎使用du扫描大目录可能引发I/O负载飙升。我曾因为扫描一个包含数百万小文件的目录导致数据库响应延迟。1.2 空间异常的特征识别健康的磁盘空间消耗应该符合目录树规律——越靠近根目录的层级占用空间越大。当出现以下反常情况时需要特别注意/var/log爆满日志文件未轮转常见于未配置logrotate的服务/tmp异常膨胀应用程序崩溃后遗留临时文件隐藏目录占用如Docker的/var/lib/docker/overlay2可能悄悄吞噬空间已删除文件未释放被进程占用的文件虽然已删除但空间未释放上周我就遇到一个典型案例某台服务器df显示根目录已用98%但du统计所有子目录总和只有30G。最终用lsof | grep deleted发现是个Java进程持有了60G的已删除日志文件重启应用后空间立即释放。2. 空间清理实战手册2.1 精准定位大文件find命令是空间清理的瑞士军刀。这个组合命令我每天至少用三次find / -type f -size 100M -exec ls -lh {} 2/dev/null | awk {print $5,$9}解释下关键参数-type f只搜索普通文件排除目录、设备文件等-size 100M查找大于100MB的文件2/dev/null屏蔽权限错误提示awk提取文件大小和路径对于时间维度的大文件查找我常用find /var/log -type f -mtime 30 -exec du -h {} | sort -h这个命令找出/var/log下修改时间超过30天的文件并按大小排序。结合业务情况可以安全删除部分历史日志。2.2 日志文件的处理艺术日志文件是最常见的空间杀手。除了用find手动清理更推荐配置logrotate实现自动化管理。这是我的nginx日志轮转配置示例/var/log/nginx/*.log { daily missingok rotate 30 compress delaycompress notifempty create 640 www-data adm sharedscripts postrotate /usr/bin/systemctl reload nginx /dev/null endscript }关键参数说明daily按天轮转rotate 30保留30个历史版本compress启用gzip压缩历史日志delaycompress延迟压缩前一个版本方便排查最新问题经验对于高流量服务建议将日志直接写入到独立分区避免日志爆满影响系统运行。2.3 容器与虚拟机的空间回收Docker的存储驱动可能成为空间黑洞。这个命令组合是我的清理利器docker system prune -af --volumes它会清理所有停止的容器未被任何容器引用的网络悬空的镜像和构建缓存未使用的卷对于Kubernetes环境记得定期清理dead podskubectl get pods --all-namespaces | grep Evicted | awk {print $1,$2} | xargs -L1 kubectl delete pod -n3. 高级诊断技巧3.1 空间不释放之谜当df显示空间已满但du统计不足时通常是有进程持有已删除的文件。诊断步骤查找被删除但仍被占用的文件lsof L1 | grep deleted确认占用进程ps -fp $(lsof L1 | grep deleted | awk {print $2} | sort -u)安全处理方案重启相关进程最彻底清空文件内容适用于日志文件truncate -s 0 /proc/pid/fd/文件描述符3.2 文件系统级别的诊断对于ext4文件系统可以用tune2fs检查保留块tune2fs -l /dev/sda1 | grep -i block count默认会保留5%的空间给root用户对于大容量数据盘可以适当降低tune2fs -m 1 /dev/sda1 # 调整为1%XFS文件系统则需要用xfs_infoxfs_info /dev/sdb14. 预防性维护策略4.1 自动化监控方案我推荐使用PrometheusAlertmanager配置磁盘预警规则groups: - name: disk.rules rules: - alert: DiskSpaceCritical expr: 100 - (node_filesystem_avail_bytes{mountpoint/} * 100 / node_filesystem_size_bytes{mountpoint/}) 90 for: 5m labels: severity: critical annotations: summary: Critical disk space on {{ $labels.instance }} ({{ $labels.mountpoint }}) description: {{ $labels.mountpoint }} on {{ $labels.instance }} has only {{ printf %.2f $value }}% free space4.2 文件系统选择建议根据使用场景选择合适文件系统常规用途ext4稳定可靠海量小文件XFS高性能处理inode容器存储btrfs/zfs支持快照和压缩对于数据库等IO敏感型应用建议单独分配高性能磁盘并采用noatime挂载选项减少元数据写入UUIDxxxx /data ext4 defaults,noatime,nodiratime 0 25. 特殊场景处理5.1 只读文件系统修复当文件系统因错误变为只读时可以尝试检查内核日志dmesg | grep -i error\|read-only强制fsck检查需卸载分区umount /dev/sda1 fsck -y /dev/sda1 mount -a5.2 LVM空间扩展对于LVM管理的磁盘扩展空间流程物理卷扩容pvresize /dev/sdb逻辑卷扩展lvextend -L 20G /dev/vg00/lv_root文件系统扩容resize2fs /dev/vg00/lv_root # ext4 xfs_growfs /mountpoint # XFS在云环境中这些操作可能需要先扩展底层虚拟磁盘。以AWS为例扩展EBS卷后需要执行growpart /dev/xvda 1 resize2fs /dev/xvda1