1. 问题本质为什么“磁盘空间不足”报错明明df -h显示还有几十GB刚接手一台跑着日志服务的CentOS服务器凌晨三点收到告警mkdir: cannot create directory ‘/var/log/app/new’: No space left on device。我第一反应是——不可能啊df -h一看/var/log所在分区/dev/sda1还剩42GBdu -sh /var/log也才占了不到8GB。重启服务、清空临时文件、甚至删掉几个大日志包问题照旧。直到我敲下df -i终端返回一行刺眼的输出/dev/sda1 100% 999999/999999。那一刻我才真正理解“No space left on device”这个错误提示根本不是在说“磁盘块block没了”而是在说“inode用光了”。Linux文件系统里每个文件、每个目录、甚至每个软链接都必须占用一个唯一的inode编号。它就像一张“身份证登记表”记录着文件的权限、所有者、时间戳、数据块位置等元信息。当这张表填满了哪怕磁盘块还堆着山一样多的空闲空间系统也坚决不给你发新“身份证”于是mkdir、touch、cp这些创建新文件或目录的操作全部被无情拒绝。这和Windows的“磁盘空间不足”提示有本质区别——Windows只管簇cluster是否够用而Linux同时管两件事数据块block够不够存内容inode够不够发身份。绝大多数新手、甚至不少运维老手在第一次遇到这个问题时都会本能地去查df -h然后陷入“明明有空间却报错”的逻辑死循环。热搜词里反复出现的“电脑有内存但显示磁盘空间不足”、“mac vscode no space left on device”背后十有八九就是这个隐形杀手。它不声不响专挑高并发、小文件密集型场景下手比如日志轮转、容器镜像缓存、Git仓库、Web应用的session存储——这些地方动辄生成成千上万个几KB大小的文件迅速耗尽inode而df -h却始终显示“一切安好”。所以排查的第一步永远不是df -h而是df -i。这是Linux系统管理员的肌肉记忆也是你和真正懂行的人之间最朴素的一道分水岭。2. 深度拆解inode是什么它怎么被耗尽哪些操作最危险2.1 inode文件系统的“户籍档案”你可以把inode想象成一个城市的户籍管理系统。每栋房子文件或目录都需要在公安局文件系统登记一个唯一的户口本inode。这个户口本上不记录房子内部装修文件内容但会详细记载房主是谁uid/gid谁能进、谁能改、谁能删rwx权限房子建于哪年哪月atime/mtime/ctime房子的“门牌号”在哪条街哪个巷指向数据块的指针房子是平房还是楼房文件类型普通文件、目录、符号链接、设备文件等关键点在于inode数量在文件系统格式化时就固定了无法动态扩容。比如你用mkfs.ext4 /dev/sdb1创建一个分区默认每16KB磁盘空间分配一个inode。这意味着一个1TB的分区理论最大inode数约为1000 * 1024 * 1024 * 1024 / 16384 ≈ 67 million。听起来很多但如果你的业务每天生成10万个5KB的日志文件一年下来就吃掉3650万个inode——还没算上中间产生的临时文件、锁文件、Git对象……半年就见底。2.2 高危操作清单谁在偷偷透支你的inode额度不是所有文件都“平等”消耗inode。以下操作是真正的“inode收割机”必须重点监控日志轮转logrotate配置不当默认配置常设rotate 10即保留10个历史日志。但如果日志本身是按小时切分hourly一天就产生24个文件10天就是240个。更致命的是某些程序如Nginx在轮转时会先cp再rm瞬间inode翻倍。实测某电商后台因logrotate未启用copytruncate单次轮转触发mkdir失败导致订单接口雪崩。容器与Docker镜像层Docker镜像由多个只读层layer叠加而成每个层都是一个独立的文件系统快照包含海量小文件.so、.pyc、配置模板。docker images看到的只是顶层但df -i反映的是底层存储驱动如overlay2的总inode使用量。一台跑着20个微服务的宿主机/var/lib/docker/overlay2目录下常有百万级inode占用。Git仓库的.git/objects目录Git将每个commit、blob、tree都存为独立文件且默认不压缩。一个中等规模的Java项目git clone后.git/objects可能生成5万个4KB的松散对象文件。git gc虽能打包但若长期不执行inode就成了定时炸弹。临时文件与锁文件泛滥某Python爬虫框架每次请求生成一个/tmp/.lock_XXXXX文件但异常退出时不清理。运行一周后/tmp目录下堆积20万个锁文件df -i直接爆红。类似情况在PHP的session.save_path、Node.js的npm cache中极为常见。邮件队列与Spool目录sendmail或postfix的/var/spool/mqueue目录每封待发邮件对应一个控制文件一个数据文件双倍消耗inode。垃圾邮件攻击时该目录可瞬间生成数万文件。提示find /path -xdev -type f | wc -l可统计指定路径下所有文件总数是快速定位inode大户的土办法。但注意-xdev参数避免跨分区统计否则结果失真。2.3 为什么du和df结果差异巨大这是新手最困惑的点。du -sh /var/log显示8GBdf -h /var/log显示已用95%但df -i却显示100%。原因在于du统计的是文件实际占用的数据块总和它遍历目录树累加每个文件的st_blocks * 512字节。df无参数统计的是整个文件系统中已分配的数据块总量包括被删除但未释放的文件即仍有进程打开的“幽灵文件”、文件系统元数据superblock、group descriptors、以及预留的root空间默认5%。df -i统计的是已分配的inode总数与文件大小完全无关。三者统计维度不同自然结果不同。一个典型的“幽灵文件”场景某Java应用日志文件被rm删除但JVM进程仍在向其fd写入。此时du已不计入该文件df -h仍显示其占用的空间未释放而df -i则早已释放其inode——所以df -i满而df -h不满恰恰说明问题出在inode而非磁盘块。3. 实战排查四步精准定位inode耗尽源头3.1 第一步确认是否真是inode耗尽别跳过这一步很多“No space left on device”其实是其他原因比如文件系统损坏dmesg | grep -i ext4.*error磁盘硬件故障smartctl -a /dev/sda用户配额超限quota -u username/tmp挂载为tmpfs且内存不足df -h /tmp看是否挂载在tmpfs标准诊断流程# 1. 查看inode使用率核心 df -i # 2. 对比磁盘块使用率确认差异 df -h # 3. 检查是否有进程持有已删除文件幽灵文件 lsof L1 # 4. 检查文件系统状态 dmesg | tail -20 tune2fs -l /dev/sda1 | grep -E (Inode|Block)如果df -i显示某个分区Use%为100%而df -h显示Use%低于90%基本可锁定为inode耗尽。此时lsof L1输出为空则排除幽灵文件若有大量输出说明是进程未释放句柄导致空间无法回收需针对性kill进程。3.2 第二步定位inode消耗大户精确到目录df -i只能告诉你哪个分区满了但不知道是哪个目录在作祟。这里有个高效技巧用find配合-xdev和-printf按子目录统计文件数。# 进入目标分区根目录如/var/log cd /var/log # 统计当前目录下所有一级子目录的文件总数含隐藏文件 find . -maxdepth 1 -mindepth 1 -xdev -printf %p/ | while read dir; do echo $(find $dir -xdev -type f | wc -l) $dir; done | sort -nr | head -10 # 输出示例 # 124567 ./nginx/ # 89234 ./app/ # 45678 ./audit/这个命令的关键在于-maxdepth 1 -mindepth 1只遍历当前目录下的直接子目录不递归深层保证速度。-xdev严格限制在当前文件系统内避免跨分区误统计。find $dir -xdev -type f | wc -l对每个子目录单独统计普通文件数排除目录、设备文件等。sort -nr按数字逆序排列head -10取Top10。我在线上环境实测一个/var/log分区有200多个子目录此命令3秒内完成扫描精准定位到./nginx/目录独占12万文件而其他目录均在1万以下。接着进入./nginx/用同样方法下钻cd ./nginx find . -maxdepth 1 -mindepth 1 -xdev -printf %p/ | while read dir; do echo $(find $dir -xdev -type f | wc -l) $dir; done | sort -nr | head -5发现./access/子目录占了其中11万文件——原来是Nginx配置了access_log /var/log/nginx/access/year_month_day.log按天切分但日志轮转脚本漏掉了olddir参数导致旧日志从未归档全部堆积在access/下。3.3 第三步分析文件特征判断是否可安全清理找到罪魁祸首目录后不能盲目rm -rf。必须分析文件类型、年龄、归属避免误删关键数据。常用分析命令组合# 1. 查看该目录下文件类型分布哪些是日志哪些是临时文件 find ./access -xdev -type f -printf %f\n | awk -F. {print $NF} | sort | uniq -c | sort -nr # 输出示例 # 112345 log # 1200 tmp # 890 gz # 2. 查看文件年龄分布是否全是陈年旧账 find ./access -xdev -type f -printf %T %p\n | sort -n | head -5 # 最老的5个 find ./access -xdev -type f -printf %T %p\n | sort -nr | head -5 # 最新的5个 # 3. 查看文件大小分布是否全是小文件 find ./access -xdev -type f -printf %s %p\n | awk $11024 {count} END{print 小于1KB文件数:, count} # 4. 查看文件属主是否属于特定服务 find ./access -xdev -type f -printf %u %p\n | awk {print $1} | sort | uniq -c | sort -nr在Nginx案例中分析结果显示所有文件扩展名均为log无gz或tmp最老文件时间为2022年1月最新为昨天99.8%的文件小于1KB所有文件属主为nginx用户。这明确指向这是Nginx未轮转的原始访问日志且已积累两年。根据公司日志保留策略仅保留90天可安全清理2022年及2023年的日志。3.4 第四步安全清理与验证清理前务必备份策略并确认无进程正在写入该目录。安全清理三步法停止相关服务防止清理时写入新文件systemctl stop nginx # 或 kill -USR1 $(cat /var/run/nginx.pid) # 发送优雅重载信号让Nginx关闭旧日志文件句柄归档而非直接删除留有回滚余地# 创建归档目录 mkdir -p /backup/nginx_old_logs # 将2022-2023年日志移动到归档目录利用mv原子性比cprm更安全 find ./access -xdev -name access_202[23]*.log -exec mv {} /backup/nginx_old_logs/ \; # 验证移动后原目录文件数 find ./access -xdev -type f | wc -l # 应显著下降清理并验证inode释放# 如果归档后仍需彻底删除如磁盘空间也紧张 find /backup/nginx_old_logs -xdev -type f -name *.log -mtime 90 -delete # 强制刷新文件系统缓存部分旧内核需要 echo 3 /proc/sys/vm/drop_caches # 验证结果 df -i # Use%应明显下降 touch /var/log/test_file rm /var/log/test_file # 测试mkdir/touch是否恢复注意rm -rf在高inode压力下可能极慢因为要逐个释放inode。mv操作则几乎瞬时是首选方案。另外echo 3 /proc/sys/vm/drop_caches并非必需但在某些内核版本下inode释放存在延迟执行后可立即看到df -i变化。4. 根治方案从配置、监控到自动化防御4.1 预防性配置源头控制inode消耗A. 日志轮转logrotate黄金配置针对Nginx/etc/logrotate.d/nginx应包含/var/log/nginx/*.log { daily missingok rotate 30 # 保留30天而非默认10天 compress delaycompress # 延迟压缩避免轮转时CPU飙升 notifempty create 0644 nginx nginx # 确保新日志权限正确 sharedscripts postrotate # 关键通知Nginx重新打开日志文件 if [ -f /var/run/nginx.pid ]; then kill -USR1 $(cat /var/run/nginx.pid) fi endscript }sharedscripts确保postrotate只执行一次kill -USR1让Nginx优雅关闭旧日志句柄避免cp操作双倍消耗inode。B. Docker存储优化对于Docker修改/etc/docker/daemon.json{ storage-driver: overlay2, storage-opts: [ overlay2.override_kernel_checktrue ], log-driver: journald, // 避免json-file驱动产生海量小文件 default-ulimits: { nofile: { Name: nofile, Hard: 65536, Soft: 65536 } } }并定期执行# 清理已停止容器的层 docker system prune -f # 清理悬空镜像dangling images docker image prune -f # 清理构建缓存BuildKit docker builder prune -fC. Git仓库瘦身在CI/CD流水线中加入# 克隆时启用稀疏检出减少文件数 git clone --filterblob:none https://repo.git # 定期GC git gc --aggressive --prunenow # 启用reflog自动过期 git config --global gc.pruneExpire 30.days4.2 监控告警把问题消灭在萌芽仅靠人工排查是救火必须建立主动监控。推荐使用Prometheus Node Exporter方案关键指标采集node_filesystem_files_free{mountpoint/var/log}剩余inode数node_filesystem_files{mountpoint/var/log}总inode数计算使用率100 - (node_filesystem_files_free / node_filesystem_files * 100)告警规则prometheus.yml- alert: InodeUsageHigh expr: 100 - (node_filesystem_files_free{jobnode} / node_filesystem_files{jobnode} * 100) 85 for: 10m labels: severity: warning annotations: summary: High inode usage on {{ $labels.mountpoint }} description: Inode usage is {{ $value }}% on {{ $labels.instance }}:{{ $labels.mountpoint }} - alert: InodeExhausted expr: 100 - (node_filesystem_files_free{jobnode} / node_filesystem_files{jobnode} * 100) 95 for: 2m labels: severity: critical annotations: summary: Inode exhausted on {{ $labels.mountpoint }} description: Inode usage is {{ $value }}% on {{ $labels.instance }}:{{ $labels.mountpoint }}. mkdir/touch will fail!本地简易监控脚本适用于无Prometheus环境#!/bin/bash # /usr/local/bin/check_inode.sh THRESHOLD85 for mount in $(df -i | awk NR1 {print $6}); do use_pct$(df -i $mount | awk NR2 {print $5} | sed s/%//) if [ $use_pct -gt $THRESHOLD ]; then echo ALERT: Inode usage $use_pct% on $mount | mail -s INODE WARNING adminexample.com logger Inode usage high ($use_pct%) on $mount fi done加入crontab*/5 * * * * /usr/local/bin/check_inode.sh4.3 自动化修复一键清理脚本将排查流程封装为可复用脚本降低响应时间#!/bin/bash # /usr/local/bin/clean_inode.sh # Usage: clean_inode.sh /var/log 90 # 清理90天前的文件 if [ $# -ne 2 ]; then echo Usage: $0 target_dir days exit 1 fi TARGET_DIR$1 DAYS$2 if [ ! -d $TARGET_DIR ]; then echo Error: $TARGET_DIR does not exist exit 1 fi echo Starting inode cleanup for $TARGET_DIR (files older than $DAYS days) # Step 1: Find and list candidates CANDIDATES$(find $TARGET_DIR -xdev -type f -mtime $DAYS | head -1000) COUNT$(echo $CANDIDATES | wc -l) if [ $COUNT -eq 0 ]; then echo No files older than $DAYS days found. exit 0 fi echo Found $COUNT candidate files. Top 10: echo $CANDIDATES | head -10 # Step 2: Dry-run confirmation read -p Proceed to delete these files? (y/N): -n 1 -r echo if [[ ! $REPLY ~ ^[Yy]$ ]]; then echo Aborted. exit 0 fi # Step 3: Actual deletion with progress echo Deleting... find $TARGET_DIR -xdev -type f -mtime $DAYS -print0 | xargs -0 -r rm -f # Step 4: Verify FREE_INODES$(df -i $TARGET_DIR | awk NR2 {print $4}) TOTAL_INODES$(df -i $TARGET_DIR | awk NR2 {print $3}) USE_PCT$((100 - FREE_INODES * 100 / TOTAL_INODES)) echo Cleanup completed. Current inode usage: ${USE_PCT}% df -i $TARGET_DIR | awk NR2 {print Free:, $4, /, $3}赋予执行权限chmod x /usr/local/bin/clean_inode.sh运维人员只需clean_inode.sh /var/log 905秒内完成评估与清理。5. 常见问题速查与独家避坑心得5.1 典型问题速查表现象可能原因快速验证命令解决方案mkdir失败df -h显示空间充足df -i显示100%inode耗尽df -i按本文3.2节定位并清理touch新建文件失败但ls能看到同名文件文件被进程占用幽灵文件lsof L1kill -9 PID或重启服务df -h显示已用100%但du -sh /远小于此存在被删除但未释放的大文件lsof L1 | grep deletedkill -HUP PID或重启进程docker build失败报“No space left”overlay2层inode不足df -i /var/lib/dockerdocker system prune -f 优化Docker配置WSL2中VS Code报“No space left”WSL2虚拟硬盘动态扩容失效wsl --shutdown 重启在Windows中手动调整WSL2磁盘大小5.2 我踩过的坑与硬核经验坑1rm -rf在inode满时卡死以为系统挂了实情rm需要为每个被删文件释放inode当inode池枯竭时释放操作本身就会阻塞。解决方案先mv到其他分区再rm。或者用find ... -delete替代rm -rf前者是unlink()系统调用后者是shell命令前者效率更高。坑2logrotate配置了compress但gzip进程崩溃导致轮转中断现象/var/log/nginx/access.log.1存在但access.log.2.gz缺失access.log.1被持续写入。logrotate日志里有gzip: command not found。根源PATH环境变量在cron中被重置。解决在/etc/logrotate.d/nginx中显式指定compresscmd /usr/bin/gzip。坑3df -i显示/根分区100%但find / -xdev -type f \| wc -l结果远小于inode总数这是经典陷阱/proc、/sys、/dev这些虚拟文件系统不占用真实inode但find会尝试进入它们并报错。正确统计命令find / -xdev -type f -printf . \| wc -c。-printf .避免输出长路径wc -c统计字符数比wc -l快10倍。坑4云服务器/dev/vda1inode用尽但df -i看不到具体目录云平台如AWS EC2的根分区常采用XFS文件系统其inode分配策略与ext4不同。XFS默认inode64模式但小文件密集场景下仍会耗尽。解决方案xfs_info /查看imaxpct值inode最大占比若为5说明inode只占5%磁盘空间需重建文件系统或迁移数据。坑5mkdir失败后touch也失败但echo test file成功这是因为echo file会覆盖写入不创建新inode而touch和mkdir必须申请新inode。这正是区分inode问题与磁盘块问题的黄金测试法——能重定向写入但不能创建新文件100%是inode耗尽。最后分享一个小技巧在/etc/fstab中为关键分区如/var/log添加noatime,nodiratime挂载选项。它禁止更新文件访问时间戳能显著减少元数据写入间接降低inode压力。虽然不直接增加inode但在高IO场景下每年可减少数百万次不必要的inode更新操作。这就像给高速公路上的收费站装ETC不增加车道却让车流更顺畅。
Linux inode耗尽：磁盘有空间却报“No space left”
1. 问题本质为什么“磁盘空间不足”报错明明df -h显示还有几十GB刚接手一台跑着日志服务的CentOS服务器凌晨三点收到告警mkdir: cannot create directory ‘/var/log/app/new’: No space left on device。我第一反应是——不可能啊df -h一看/var/log所在分区/dev/sda1还剩42GBdu -sh /var/log也才占了不到8GB。重启服务、清空临时文件、甚至删掉几个大日志包问题照旧。直到我敲下df -i终端返回一行刺眼的输出/dev/sda1 100% 999999/999999。那一刻我才真正理解“No space left on device”这个错误提示根本不是在说“磁盘块block没了”而是在说“inode用光了”。Linux文件系统里每个文件、每个目录、甚至每个软链接都必须占用一个唯一的inode编号。它就像一张“身份证登记表”记录着文件的权限、所有者、时间戳、数据块位置等元信息。当这张表填满了哪怕磁盘块还堆着山一样多的空闲空间系统也坚决不给你发新“身份证”于是mkdir、touch、cp这些创建新文件或目录的操作全部被无情拒绝。这和Windows的“磁盘空间不足”提示有本质区别——Windows只管簇cluster是否够用而Linux同时管两件事数据块block够不够存内容inode够不够发身份。绝大多数新手、甚至不少运维老手在第一次遇到这个问题时都会本能地去查df -h然后陷入“明明有空间却报错”的逻辑死循环。热搜词里反复出现的“电脑有内存但显示磁盘空间不足”、“mac vscode no space left on device”背后十有八九就是这个隐形杀手。它不声不响专挑高并发、小文件密集型场景下手比如日志轮转、容器镜像缓存、Git仓库、Web应用的session存储——这些地方动辄生成成千上万个几KB大小的文件迅速耗尽inode而df -h却始终显示“一切安好”。所以排查的第一步永远不是df -h而是df -i。这是Linux系统管理员的肌肉记忆也是你和真正懂行的人之间最朴素的一道分水岭。2. 深度拆解inode是什么它怎么被耗尽哪些操作最危险2.1 inode文件系统的“户籍档案”你可以把inode想象成一个城市的户籍管理系统。每栋房子文件或目录都需要在公安局文件系统登记一个唯一的户口本inode。这个户口本上不记录房子内部装修文件内容但会详细记载房主是谁uid/gid谁能进、谁能改、谁能删rwx权限房子建于哪年哪月atime/mtime/ctime房子的“门牌号”在哪条街哪个巷指向数据块的指针房子是平房还是楼房文件类型普通文件、目录、符号链接、设备文件等关键点在于inode数量在文件系统格式化时就固定了无法动态扩容。比如你用mkfs.ext4 /dev/sdb1创建一个分区默认每16KB磁盘空间分配一个inode。这意味着一个1TB的分区理论最大inode数约为1000 * 1024 * 1024 * 1024 / 16384 ≈ 67 million。听起来很多但如果你的业务每天生成10万个5KB的日志文件一年下来就吃掉3650万个inode——还没算上中间产生的临时文件、锁文件、Git对象……半年就见底。2.2 高危操作清单谁在偷偷透支你的inode额度不是所有文件都“平等”消耗inode。以下操作是真正的“inode收割机”必须重点监控日志轮转logrotate配置不当默认配置常设rotate 10即保留10个历史日志。但如果日志本身是按小时切分hourly一天就产生24个文件10天就是240个。更致命的是某些程序如Nginx在轮转时会先cp再rm瞬间inode翻倍。实测某电商后台因logrotate未启用copytruncate单次轮转触发mkdir失败导致订单接口雪崩。容器与Docker镜像层Docker镜像由多个只读层layer叠加而成每个层都是一个独立的文件系统快照包含海量小文件.so、.pyc、配置模板。docker images看到的只是顶层但df -i反映的是底层存储驱动如overlay2的总inode使用量。一台跑着20个微服务的宿主机/var/lib/docker/overlay2目录下常有百万级inode占用。Git仓库的.git/objects目录Git将每个commit、blob、tree都存为独立文件且默认不压缩。一个中等规模的Java项目git clone后.git/objects可能生成5万个4KB的松散对象文件。git gc虽能打包但若长期不执行inode就成了定时炸弹。临时文件与锁文件泛滥某Python爬虫框架每次请求生成一个/tmp/.lock_XXXXX文件但异常退出时不清理。运行一周后/tmp目录下堆积20万个锁文件df -i直接爆红。类似情况在PHP的session.save_path、Node.js的npm cache中极为常见。邮件队列与Spool目录sendmail或postfix的/var/spool/mqueue目录每封待发邮件对应一个控制文件一个数据文件双倍消耗inode。垃圾邮件攻击时该目录可瞬间生成数万文件。提示find /path -xdev -type f | wc -l可统计指定路径下所有文件总数是快速定位inode大户的土办法。但注意-xdev参数避免跨分区统计否则结果失真。2.3 为什么du和df结果差异巨大这是新手最困惑的点。du -sh /var/log显示8GBdf -h /var/log显示已用95%但df -i却显示100%。原因在于du统计的是文件实际占用的数据块总和它遍历目录树累加每个文件的st_blocks * 512字节。df无参数统计的是整个文件系统中已分配的数据块总量包括被删除但未释放的文件即仍有进程打开的“幽灵文件”、文件系统元数据superblock、group descriptors、以及预留的root空间默认5%。df -i统计的是已分配的inode总数与文件大小完全无关。三者统计维度不同自然结果不同。一个典型的“幽灵文件”场景某Java应用日志文件被rm删除但JVM进程仍在向其fd写入。此时du已不计入该文件df -h仍显示其占用的空间未释放而df -i则早已释放其inode——所以df -i满而df -h不满恰恰说明问题出在inode而非磁盘块。3. 实战排查四步精准定位inode耗尽源头3.1 第一步确认是否真是inode耗尽别跳过这一步很多“No space left on device”其实是其他原因比如文件系统损坏dmesg | grep -i ext4.*error磁盘硬件故障smartctl -a /dev/sda用户配额超限quota -u username/tmp挂载为tmpfs且内存不足df -h /tmp看是否挂载在tmpfs标准诊断流程# 1. 查看inode使用率核心 df -i # 2. 对比磁盘块使用率确认差异 df -h # 3. 检查是否有进程持有已删除文件幽灵文件 lsof L1 # 4. 检查文件系统状态 dmesg | tail -20 tune2fs -l /dev/sda1 | grep -E (Inode|Block)如果df -i显示某个分区Use%为100%而df -h显示Use%低于90%基本可锁定为inode耗尽。此时lsof L1输出为空则排除幽灵文件若有大量输出说明是进程未释放句柄导致空间无法回收需针对性kill进程。3.2 第二步定位inode消耗大户精确到目录df -i只能告诉你哪个分区满了但不知道是哪个目录在作祟。这里有个高效技巧用find配合-xdev和-printf按子目录统计文件数。# 进入目标分区根目录如/var/log cd /var/log # 统计当前目录下所有一级子目录的文件总数含隐藏文件 find . -maxdepth 1 -mindepth 1 -xdev -printf %p/ | while read dir; do echo $(find $dir -xdev -type f | wc -l) $dir; done | sort -nr | head -10 # 输出示例 # 124567 ./nginx/ # 89234 ./app/ # 45678 ./audit/这个命令的关键在于-maxdepth 1 -mindepth 1只遍历当前目录下的直接子目录不递归深层保证速度。-xdev严格限制在当前文件系统内避免跨分区误统计。find $dir -xdev -type f | wc -l对每个子目录单独统计普通文件数排除目录、设备文件等。sort -nr按数字逆序排列head -10取Top10。我在线上环境实测一个/var/log分区有200多个子目录此命令3秒内完成扫描精准定位到./nginx/目录独占12万文件而其他目录均在1万以下。接着进入./nginx/用同样方法下钻cd ./nginx find . -maxdepth 1 -mindepth 1 -xdev -printf %p/ | while read dir; do echo $(find $dir -xdev -type f | wc -l) $dir; done | sort -nr | head -5发现./access/子目录占了其中11万文件——原来是Nginx配置了access_log /var/log/nginx/access/year_month_day.log按天切分但日志轮转脚本漏掉了olddir参数导致旧日志从未归档全部堆积在access/下。3.3 第三步分析文件特征判断是否可安全清理找到罪魁祸首目录后不能盲目rm -rf。必须分析文件类型、年龄、归属避免误删关键数据。常用分析命令组合# 1. 查看该目录下文件类型分布哪些是日志哪些是临时文件 find ./access -xdev -type f -printf %f\n | awk -F. {print $NF} | sort | uniq -c | sort -nr # 输出示例 # 112345 log # 1200 tmp # 890 gz # 2. 查看文件年龄分布是否全是陈年旧账 find ./access -xdev -type f -printf %T %p\n | sort -n | head -5 # 最老的5个 find ./access -xdev -type f -printf %T %p\n | sort -nr | head -5 # 最新的5个 # 3. 查看文件大小分布是否全是小文件 find ./access -xdev -type f -printf %s %p\n | awk $11024 {count} END{print 小于1KB文件数:, count} # 4. 查看文件属主是否属于特定服务 find ./access -xdev -type f -printf %u %p\n | awk {print $1} | sort | uniq -c | sort -nr在Nginx案例中分析结果显示所有文件扩展名均为log无gz或tmp最老文件时间为2022年1月最新为昨天99.8%的文件小于1KB所有文件属主为nginx用户。这明确指向这是Nginx未轮转的原始访问日志且已积累两年。根据公司日志保留策略仅保留90天可安全清理2022年及2023年的日志。3.4 第四步安全清理与验证清理前务必备份策略并确认无进程正在写入该目录。安全清理三步法停止相关服务防止清理时写入新文件systemctl stop nginx # 或 kill -USR1 $(cat /var/run/nginx.pid) # 发送优雅重载信号让Nginx关闭旧日志文件句柄归档而非直接删除留有回滚余地# 创建归档目录 mkdir -p /backup/nginx_old_logs # 将2022-2023年日志移动到归档目录利用mv原子性比cprm更安全 find ./access -xdev -name access_202[23]*.log -exec mv {} /backup/nginx_old_logs/ \; # 验证移动后原目录文件数 find ./access -xdev -type f | wc -l # 应显著下降清理并验证inode释放# 如果归档后仍需彻底删除如磁盘空间也紧张 find /backup/nginx_old_logs -xdev -type f -name *.log -mtime 90 -delete # 强制刷新文件系统缓存部分旧内核需要 echo 3 /proc/sys/vm/drop_caches # 验证结果 df -i # Use%应明显下降 touch /var/log/test_file rm /var/log/test_file # 测试mkdir/touch是否恢复注意rm -rf在高inode压力下可能极慢因为要逐个释放inode。mv操作则几乎瞬时是首选方案。另外echo 3 /proc/sys/vm/drop_caches并非必需但在某些内核版本下inode释放存在延迟执行后可立即看到df -i变化。4. 根治方案从配置、监控到自动化防御4.1 预防性配置源头控制inode消耗A. 日志轮转logrotate黄金配置针对Nginx/etc/logrotate.d/nginx应包含/var/log/nginx/*.log { daily missingok rotate 30 # 保留30天而非默认10天 compress delaycompress # 延迟压缩避免轮转时CPU飙升 notifempty create 0644 nginx nginx # 确保新日志权限正确 sharedscripts postrotate # 关键通知Nginx重新打开日志文件 if [ -f /var/run/nginx.pid ]; then kill -USR1 $(cat /var/run/nginx.pid) fi endscript }sharedscripts确保postrotate只执行一次kill -USR1让Nginx优雅关闭旧日志句柄避免cp操作双倍消耗inode。B. Docker存储优化对于Docker修改/etc/docker/daemon.json{ storage-driver: overlay2, storage-opts: [ overlay2.override_kernel_checktrue ], log-driver: journald, // 避免json-file驱动产生海量小文件 default-ulimits: { nofile: { Name: nofile, Hard: 65536, Soft: 65536 } } }并定期执行# 清理已停止容器的层 docker system prune -f # 清理悬空镜像dangling images docker image prune -f # 清理构建缓存BuildKit docker builder prune -fC. Git仓库瘦身在CI/CD流水线中加入# 克隆时启用稀疏检出减少文件数 git clone --filterblob:none https://repo.git # 定期GC git gc --aggressive --prunenow # 启用reflog自动过期 git config --global gc.pruneExpire 30.days4.2 监控告警把问题消灭在萌芽仅靠人工排查是救火必须建立主动监控。推荐使用Prometheus Node Exporter方案关键指标采集node_filesystem_files_free{mountpoint/var/log}剩余inode数node_filesystem_files{mountpoint/var/log}总inode数计算使用率100 - (node_filesystem_files_free / node_filesystem_files * 100)告警规则prometheus.yml- alert: InodeUsageHigh expr: 100 - (node_filesystem_files_free{jobnode} / node_filesystem_files{jobnode} * 100) 85 for: 10m labels: severity: warning annotations: summary: High inode usage on {{ $labels.mountpoint }} description: Inode usage is {{ $value }}% on {{ $labels.instance }}:{{ $labels.mountpoint }} - alert: InodeExhausted expr: 100 - (node_filesystem_files_free{jobnode} / node_filesystem_files{jobnode} * 100) 95 for: 2m labels: severity: critical annotations: summary: Inode exhausted on {{ $labels.mountpoint }} description: Inode usage is {{ $value }}% on {{ $labels.instance }}:{{ $labels.mountpoint }}. mkdir/touch will fail!本地简易监控脚本适用于无Prometheus环境#!/bin/bash # /usr/local/bin/check_inode.sh THRESHOLD85 for mount in $(df -i | awk NR1 {print $6}); do use_pct$(df -i $mount | awk NR2 {print $5} | sed s/%//) if [ $use_pct -gt $THRESHOLD ]; then echo ALERT: Inode usage $use_pct% on $mount | mail -s INODE WARNING adminexample.com logger Inode usage high ($use_pct%) on $mount fi done加入crontab*/5 * * * * /usr/local/bin/check_inode.sh4.3 自动化修复一键清理脚本将排查流程封装为可复用脚本降低响应时间#!/bin/bash # /usr/local/bin/clean_inode.sh # Usage: clean_inode.sh /var/log 90 # 清理90天前的文件 if [ $# -ne 2 ]; then echo Usage: $0 target_dir days exit 1 fi TARGET_DIR$1 DAYS$2 if [ ! -d $TARGET_DIR ]; then echo Error: $TARGET_DIR does not exist exit 1 fi echo Starting inode cleanup for $TARGET_DIR (files older than $DAYS days) # Step 1: Find and list candidates CANDIDATES$(find $TARGET_DIR -xdev -type f -mtime $DAYS | head -1000) COUNT$(echo $CANDIDATES | wc -l) if [ $COUNT -eq 0 ]; then echo No files older than $DAYS days found. exit 0 fi echo Found $COUNT candidate files. Top 10: echo $CANDIDATES | head -10 # Step 2: Dry-run confirmation read -p Proceed to delete these files? (y/N): -n 1 -r echo if [[ ! $REPLY ~ ^[Yy]$ ]]; then echo Aborted. exit 0 fi # Step 3: Actual deletion with progress echo Deleting... find $TARGET_DIR -xdev -type f -mtime $DAYS -print0 | xargs -0 -r rm -f # Step 4: Verify FREE_INODES$(df -i $TARGET_DIR | awk NR2 {print $4}) TOTAL_INODES$(df -i $TARGET_DIR | awk NR2 {print $3}) USE_PCT$((100 - FREE_INODES * 100 / TOTAL_INODES)) echo Cleanup completed. Current inode usage: ${USE_PCT}% df -i $TARGET_DIR | awk NR2 {print Free:, $4, /, $3}赋予执行权限chmod x /usr/local/bin/clean_inode.sh运维人员只需clean_inode.sh /var/log 905秒内完成评估与清理。5. 常见问题速查与独家避坑心得5.1 典型问题速查表现象可能原因快速验证命令解决方案mkdir失败df -h显示空间充足df -i显示100%inode耗尽df -i按本文3.2节定位并清理touch新建文件失败但ls能看到同名文件文件被进程占用幽灵文件lsof L1kill -9 PID或重启服务df -h显示已用100%但du -sh /远小于此存在被删除但未释放的大文件lsof L1 | grep deletedkill -HUP PID或重启进程docker build失败报“No space left”overlay2层inode不足df -i /var/lib/dockerdocker system prune -f 优化Docker配置WSL2中VS Code报“No space left”WSL2虚拟硬盘动态扩容失效wsl --shutdown 重启在Windows中手动调整WSL2磁盘大小5.2 我踩过的坑与硬核经验坑1rm -rf在inode满时卡死以为系统挂了实情rm需要为每个被删文件释放inode当inode池枯竭时释放操作本身就会阻塞。解决方案先mv到其他分区再rm。或者用find ... -delete替代rm -rf前者是unlink()系统调用后者是shell命令前者效率更高。坑2logrotate配置了compress但gzip进程崩溃导致轮转中断现象/var/log/nginx/access.log.1存在但access.log.2.gz缺失access.log.1被持续写入。logrotate日志里有gzip: command not found。根源PATH环境变量在cron中被重置。解决在/etc/logrotate.d/nginx中显式指定compresscmd /usr/bin/gzip。坑3df -i显示/根分区100%但find / -xdev -type f \| wc -l结果远小于inode总数这是经典陷阱/proc、/sys、/dev这些虚拟文件系统不占用真实inode但find会尝试进入它们并报错。正确统计命令find / -xdev -type f -printf . \| wc -c。-printf .避免输出长路径wc -c统计字符数比wc -l快10倍。坑4云服务器/dev/vda1inode用尽但df -i看不到具体目录云平台如AWS EC2的根分区常采用XFS文件系统其inode分配策略与ext4不同。XFS默认inode64模式但小文件密集场景下仍会耗尽。解决方案xfs_info /查看imaxpct值inode最大占比若为5说明inode只占5%磁盘空间需重建文件系统或迁移数据。坑5mkdir失败后touch也失败但echo test file成功这是因为echo file会覆盖写入不创建新inode而touch和mkdir必须申请新inode。这正是区分inode问题与磁盘块问题的黄金测试法——能重定向写入但不能创建新文件100%是inode耗尽。最后分享一个小技巧在/etc/fstab中为关键分区如/var/log添加noatime,nodiratime挂载选项。它禁止更新文件访问时间戳能显著减少元数据写入间接降低inode压力。虽然不直接增加inode但在高IO场景下每年可减少数百万次不必要的inode更新操作。这就像给高速公路上的收费站装ETC不增加车道却让车流更顺畅。