现场是这样的。文件服务器上给每个项目组设了 50G 块配额，某组备份脚本把几百万个几十字节的锁文件写进来，整块盘 inode 耗尽，其他组新建文件全部报 No space left on device。
中间走过弯路，把「文件系统 mkfs 时 inode 数量按默认比例给，小文件场景很快就见底」当成主因，改完现象没变。
真正麻烦的地方在于，几个原因的现象几乎一样。quota 只配了 blocks 软硬限，inode 配额是关着的，小文件几乎不占块空间；应用的锁文件按每秒一个生成且不清理，一天就是八万多个 inode；配额报表只看空间占用，没人关注已用 inode 数。
先确认 inode 耗尽而不是块耗尽
df -i /data && df -h /data接着查该用户已用 inode 数
repquota -u /data | sort -k8 -n | tail给用户加上 inode 硬限
setquota -u proj01 0 0 200000 250000 /data末了清理过期的锁文件并改成按天归档
find /data/proj01/lock -type f -mtime +1 -delete别只看报错消失，验证要多做一步。df -i 的已用比例回落到七成以下，repquota -u 里新增 inode 配额列并显示限额，普通用户重新创建文件不再报错。
inode 配额要在挂载时带 usrquota 且文件系统支持，改完后老用户不会自动受限，需逐个 setquota；清文件前先确认路径没被软链串走。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。