做网站案例兰州网络seo

问题描述

在日常运维中，我们发现某用户 aa 在 Samba 挂载目录下实际数据仅为 90G，但通过 quota 命令查看，其磁盘配额占用高达 158G，并且 Samba 挂载出来也显示空间占用异常：

# 查看用户配额
root@server:~# quota -vs aa
Disk quotas for user aa (uid 10120): Filesystem   space   quota   limit   grace   files   quota   limit   grace/dev/sdb1    158G    170G    200G            795k       0       0        # 查看用户目录大小
root@server:~# du -sh /home/aa
90G     /home/aa# 查看磁盘使用
root@server:~# df -h | grep /home
/dev/sdb1       4.8T  3.4T  1.2T  75% /home

因为还有其他程序在跑，所以不能重启服务器

原因分析

当 du 与 quota 显示数据严重不符时，常见的原因之一是：

有文件虽然已被删除，但仍被进程占用，其空间不会释放，仍计入 quota，但不会被 du 显示。

排查过程

使用 lsof +L1 可以列出所有“已被删除但仍被打开的文件”：

root@server:/home# lsof +L1 | grep aa
... ...
vim       31266  aa    5u   REG   8,17 72175783936     0 101525185 /home/aa/workspace/.../.csp.c.swp (deleted)

可以看到，vim 进程（PID 为 31266）仍然占用一个被删除的 .swp 文件，大小高达 72G，刚好就是多出的大小。

解决方案

尝试释放该文件所占用的空间：

# 方法一（不成功）
pkill -u aa# 方法二（不成功）
kill 31266# 方法三（成功）
kill -9 31266
# 估计是因为有锁在，导致得强制kill

杀掉进程后，空间立即释放，quota 和 Samba 空间都显示都恢复正常。

总结

当 quota 显示占用远高于实际文件大小时：

• 第一时间使用 lsof +L1 排查是否有 被删除但仍占用的文件；
• 找到具体进程后，根据情况优雅退出、重启或 kill -9 强制释放；
• 最后用 quota -vs 用户名 确认配额恢复。

这种问题常见于开发环境或长时间运行的服务日志处理，建议配合监控及时发现并自动化清理。