为什么操作系统显示已使用 6.5G，但我只看到文件/目录中有 3.6G？
在 Amazon Linux AMI（看起来像 Centos）上以 root 身份运行，有大量可用内存，没有进行交换，没有明显的文件描述符问题。我唯一能想到的是一个日志文件，它在应用程序附加到它时被删除了。
磁盘空间使用率缓慢但持续地上升至满容量（~1k/分钟，不时有非常小的下降）
有什么解释吗？有解决办法吗？
du --max-depth=1 -h /
1.2G /usr
4.0K /cgroup
22M /lib64
11M /sbin
19M /etc
52K /dev
2.1G /var
4.0K /media
0 /sys
4.0K /selinux
du：无法访问/proc/14024/task/14024/fd/4': No such file or directory du: cannot access<br/>/proc/14024/task/14024/fdinfo/4'：没有此文件或目录 du：
无法访问/proc/14024/fd/4': No such file or directory du: cannot<br/> access/proc/14024/fdinfo/4'：没有此文件或目录 0 /proc
18M /home
4.0K /logs
8.1M /bin
16K /lost+found
12M /tmp
4.0K /srv
35M /boot
79M /lib
56K /root
67M /opt
4.0K /local
4.0K /mnt
3.6G /DF-H
文件系统大小已用可用使用率% 安装在
/dev/xvda17.9G 6.5G 1.4G 84% / tmpfs 3.7G 0 3.7G 0% /dev/shmsysctl fs.文件编号 fs.文件编号 = 864 0 761182
答案1
如果已删除的文件仍被某个进程打开，则空间将不会被回收，直到该进程关闭该文件（或被终止）。如果您无法确定哪个进程正在打开某个文件，则重新启动将有所帮助，因为这样将关闭所有正在运行的进程（从而关闭所有打开的文件）。
另一个考虑因素是文件系统损坏。由于这是您的根文件系统，您可能需要重新启动并在重新启动时强制检查文件系统（shutdown -rF now）。确保您已配置为执行非交互式扫描+修复，除非您具有 KVM 访问权限或类似权限（以便您可以在启动过程中进行交互），否则如果在检查期间发现错误，您的远程机器将挂起等待本地输入。
编辑： （根据评论中的问题）
如果您知道保持文件打开的进程，则可以重新启动该特定进程（通过服务停止/启动/重新启动脚本或通过手动终止并重新启动），而不是重新启动整个实例。
此外，有些程序支持无需重新启动即可自行重置，这通常包括关闭并重新启动日志文件（如果确实是由于已删除但仍打开的日志文件导致的问题，则可解决问题）以响应发送的 SIGHUP 信号（通过kill）。以这种方式重置进程有时是更好的选择，因为它可以减少（通常为零）服务器进程无法接受新连接的时间。当您运行/etc/init.d/<service> reload而不是 时，通常会发生这种情况/etc/init.d/<service> restart（事实上，我见过以restart这种方式实现的，因此要进行正确的完全重置，您必须执行/etc/init.d/<service> stop; /etc/init.d/<service> start）。
答案2
设法回收空间，而无需重新启动通过 /proc//fd/ 中的 fd 链接保持打开状态的进程。
1）获取保存进程文件描述符的路径：
cd /proc/`lsof|grep '<deleted_file>'|head -1|awk '{print $2}'`/fd
2）找到进程fd链接：
ll | grep <deleted_file>
3）用空白覆盖（所有数据将丢失）
> <fd>