银河麒麟v10报“no space left on device”但df -h显示空间充足，实为元数据层异常：需同步排查inode耗尽、已删文件未释放、挂载覆盖三类问题。
银河麒麟V10终端报“No space left on device”却显示df -h还有几十GB剩余空间，这种矛盾现象99%不是磁盘真满了，而是系统卡在了文件系统元数据层——你手里的空间“能看见，但用不了”，必须分三路同步排查：先揪出是块（block）还是身份证（inode）耗尽，再确认有没有被进程锁住的已删文件，最后检查挂载点是否把真实数据盖住了。
第一步：确认到底是哪类“没空间”
打开终端，直接运行：
df -h && df -i
重点对比两个数字：如果“已用%”列里，【块使用率低于85%但inode使用率已达100%】，问题就锁定在小文件爆炸；如果两者都低于70%，那一定是其他原因，别再删大文件了。
注意：df -i查的是根分区（/）的inode，不是/home或/data——哪怕你只在/home下存了百万个微信截图，也不会影响根分区inode。
第二步：查inode爆满的源头目录
执行命令定位高密度小文件区：
find / -xdev -type f | awk -F/ '{d=$1; for(i=2;i
这条命令会按目录层级聚合统计文件数量，输出前8名。典型重灾区有三个：
① /var/log/journal —— systemd日志默认不压缩、不限大小，14个月服务器可能堆出32GB二进制日志，占掉上百万个inode；
② /var/spool/postfix/maildrop —— 邮件队列残留的临时文件，每个邮件一个文件，几万封积压就吃光inode；
③ /tmp/systemd-private-xxxxxx —— 服务私有临时目录，重启失败后残留的socket和pid文件长期不清理。
看到某行输出像“ 987654 /var/log/journal”时，立刻停手——这就是罪魁祸首。
第三步：精准清理，不碰业务数据
方法一：收缩journal日志（最常用）
journalctl --vacuum-size=100M
这一步会自动删除旧日志，保留最近100MB，不中断任何服务，比rm -rf安全十倍。执行后立刻再跑一次df -i，inode占用通常下降30%～60%。
方法二：清空postfix队列（仅当确认无待发邮件）
sudo postsuper -d ALL
方法三：强制清理/tmp下僵尸临时目录
sudo find /tmp -maxdepth 1 -name "systemd-private-*" -type d -mtime +7 -exec rm -rf {} \;
【不要手动删/var/log/journal下的*.journal文件】—— systemd-journald正在写入时直接rm会导致日志索引损坏，后续journalctl命令可能崩溃。
第四步：检查被进程霸占的“已删文件”
运行：
lsof +L1
如果输出非空，说明有进程正拿着已被rm的文件句柄不放。常见于nginx、java、rsyslog等长周期服务。例如看到这一行：
nginx 1234 www-data 12w REG 253,0 1.8G 987654 /var/log/nginx/access.log (deleted)
这意味着access.log虽被删，但nginx还在往里面写，磁盘空间实际没释放。此时执行：
sudo systemctl restart nginx
重启对应服务即可释放空间。不要kill -9硬杀，避免服务异常退出丢失缓冲数据。
第五步：验证挂载点是否遮挡原始数据
运行：
mount | grep "on /"
如果输出中包含类似“/dev/sda1 on / type ext4”的行，再执行：
sudo umount / && sudo du -shx / && sudo mount /
这三步操作必须连贯。如果umount后du -shx /突然显示28GB，而mount回来又变回5GB，说明根分区挂载前目录里原有大量数据被挂载动作“盖住”了——这些数据物理存在但不可见。此时需在umount状态下清理，否则所有rm操作都无效。
