删除一个巨大的 500G 不会释放磁盘空间

Question

我在这里有一台运行 Ubuntu（服务器版）的远程服务器。

昨天我注意到我的硬盘空间被占用了 100%。有一个越来越大的日志文件，所以我通过rm file.foo.

然后我跑了，df -h但存储文件的分区仍然被 100% 占用。

所以我认为重新启动可能会有所帮助并运行sudo shutdown -r now。

等了几分钟后，我无法通过 SSH 连接到服务器，所以我要求数据中心的人手动重新启动它。

那行得通，服务器启动了。

所以我df -h再次运行，现在 80% 的分区已被占用（至少有一些东西）。

接下来，我想检查什么需要那么多磁盘空间并运行sudo du -h --max-depth 1 /，结果是：

16K /lost+found
942M    /home
52K /tmp
4.0K    /mnt
236K    /dev
du: cannot access `/proc/17189/task/17189/fd/4': No such file or directory
du: cannot access `/proc/17189/task/17189/fdinfo/4': No such file or directory
du: cannot access `/proc/17189/fd/4': No such file or directory
du: cannot access `/proc/17189/fdinfo/4': No such file or directory
0   /proc
4.0K    /media
4.0K    /opt
4.0K    /srv
32K /root
3.0G    /var
393M    /lib
37M /boot
6.9M    /etc
681M    /usr
4.0K    /selinux
8.0M    /bin
9.0M    /sbin
4.0K    /cdrom
0   /sys
5.0G    /

正如您在最后一行中看到的那样，只有 5 GB 被占用（因此该文件不能在垃圾箱中或“丢失+找到”）-自从我使用rm命令以来，无论如何它都不在那里。

那么，怎么了？

我个人的猜测是，当服务器重新启动时，它以某种方式清理了我删除的那个巨大的 500GB 文件。强制手动重启可能会中断它，因此它只能清理其中的 20%。

如果我的猜测是真的，我能做些什么来修复它？

如果我的猜测是错误的，那么我的系统怎么办？

Answer 1

我的第一个猜测是，写入的任何程序file.foo仍然存在并保持文件句柄打开：当对 inode（文件）的最后一个引用被清除时，磁盘空间仅在内核眼中是“空闲的”，并且程序将文件打开计数作为参考。未来：当您移动或删除日志文件时，请记住让使用它的程序知道- 如果您真的想安全，请重新启动有问题的程序。

既然你重新启动了，虽然这在理论上是不可能的——所有的程序都应该被杀死，所以他们持有的任何引用也会消失。这留下了我能想到的两种可能性：

1. 您有一个指向您不知道的文件的硬链接。
   如果是这种情况，du并且df应该同意您在系统上使用的空间量。

2. 您的文件系统已损坏。可能处于 inode 具有正引用计数但实际上并未被任何文件系统对象指向的模式。
   这相对容易（虽然耗时）检查：在大多数 Linux 系统上，您可以通过创建一个名为/forcefsck（touch /forcefsck作为 root 用户会这样做）的文件来强制在重新启动时进行文件系统检查——然后只需重新启动并等待（一段时间！）您的系统会扫描其文件系统，以寻找诸如“丢失”的索引节点之类的具有扭曲引用计数的内容。