df显示所有空间都被占用,但du的结果不相符。

我在使用Ubuntu 12.04 LTS时遇到了问题。这是我在过去3周内第二次遇到这个问题。 第一次的情况在StackOverflow上的这个已关闭问题里有描述。 简而言之,我在一个450G的ext4系统上编译和构建Android堆栈不到20次就用完了所有的inode。
我以为通过将磁盘重新格式化为XFS来解决这个问题,以便inode存储可以增长。
今天早上,在整夜的构建之后,我只剩下不到1GB的可用空间了。除了构建Android所需的东西外,这台机器上什么都没有。我在平台源代码上总共进行了5次构建。构建会创建一些文件,然后我会立即使用“make clean”删除它们。实际上我不只剩下不到1GB的空间,但工具报告出来的确是这样。我删除了一大堆临时文件,释放了大约40GB的空间。几个小时后,即使只是闲置,我又回到了不到1GB的可用空间。
从闪存驱动器上运行Ubuntu返回的分区信息如下...
$ df
Filesystem     1K-blocks      Used Available Use% Mounted on
/dev/sda5      468521456 468255460    265996 100% /media/f71c77eb-b4cc-

$ df -i
Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/sda5      1691760 624214 1067546   37% /media/f71c77eb-b4cc-

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda5       447G  447G  260M 100% /media/f71c77eb-b4cc-

这是证据表明有些不对劲。当我运行du(带和不带--apparent-size)或者使用可视化的磁盘使用分析器时,显示我实际上只使用了大约35GB左右的空间。98.7%的已用空间在/home/eric中,但是du的总和与此不符。差异在于/home/eric/home/eric/android之间。

enter image description here

我已经阅读了这里和SO上的相关问题,它们通常建议是由打开的进程持有的已删除文件。我重新启动到一个闪存驱动器来运行这个测试,所以不应该有打开的文件。顺便说一下,/tmp是空的。
有没有一个工具可以安装在闪存驱动器上来恢复“丢失”的空间?我可以尝试在系统上释放内存并在那里运行它,但我认为最好还是从闪存驱动器上进行。
我应该以不同的方式配置这个系统吗?我宁愿不再进行擦除和安装,但我需要一个可持续的Android构建系统。
跟进 - 上周我不得不彻底清除安装并重新安装12.04以完成工作。当我本周再次进行Android构建时,我将密切关注磁盘使用情况,并在这里提供更多信息。
谢谢

1你有没有查看过为什么df和du显示不同的输出 - jokerdino
@jokerdino 是的,我按照那个帖子里的指示以及其他类似的帖子做了。我重启了系统并从闪存驱动器重新启动了。然而,在重新启动后,系统仍然显示整个磁盘已被占用。谢谢。 - Eric Cloninger
在Linux中,文件数据是引用计数的,因此你不需要像在Windows中那样经常重新启动。也许你在覆盖模拟器后台的数据文件时保持了模拟器的运行状态? - aquaherd
@EricCloninger 我必须将自己添加到遇到相同问题的用户列表中。这是我的问题,使用的是12.10版本,而这是一个11.04用户的问题 - Lucio
另外,请复制并粘贴 ls -lah ~ 的输出到 paste.ubuntu.com,并在您的问题中提供链接。 - Lucio
有时候可能是一个行为不端的应用程序,每秒向像~/.xsession-errors这样的日志文件中喷出数百条错误消息。使用sudo find /home/eric -size +1G -type f来查看异常大的文件。如果启用了日志轮转,请使用+512M、+256M。 - aquaherd
9个回答

在Oracle Linux上,当您有许多或大量的文件被删除但仍然被正在运行的进程打开时,就会出现这种情况。然后停止进程或重新启动机器可以解决问题。

在一个紧贴着日志文件的服务器上对我很有用。谢谢! - miccet
19使用 lsof +L1 命令,检查进程ID,并将其杀死。 - Jeff Tian

我最近遇到了这个问题,在我的情况下,需要运行一个fsck
我执行了touch /forcefsck && reboot命令,几分钟后,服务器恢复正常,并且突然间我丢失的6 GB 空间被释放出来了。

这通常是由目录中的文件引起的,该目录上还挂载了不同的文件系统。一个典型的修复方法是使用救援盘启动,或者在单用户模式下清空这些目录,并验证它们没有被用作挂载点(cat /proc/mountsdf -h)。

这是我的问题,不知何故,一个Docker容器在NFS共享挂载之前就已经挂载了一个文件,并且将数十GB的录音写入了根文件系统。 - SilentVoid

在你继续之前,请将系统切换到单用户模式,并对文件系统进行完整的 fsck(我真的是指完整的 fsck -f /dev/sda5),看看它显示了什么。你可能会发现磁盘上存在问题区域或者分配与实际情况不符导致的空间问题。

使用闪存驱动器上的 sudo fsck -f /dev/sda5 命令对格式为 XFS 的驱动器进行检查并没有产生任何效果。建议我使用 xfs_check 命令。执行 xfs_check /dev/sda5 命令后,没有返回任何结果。然后运行了 xfs_repair /dev/sda5 命令进行修复,但没有报告任何异常。在执行这两个命令之后,我的磁盘仍然保持 99% 充满状态。谢谢(Thx)。 - Eric Cloninger

我们可以做一个测试,du说你有10GB的可用空间,而df说只有300MB,你能写入一个大小为2GB的文件(或多个文件)吗? 如果可以,那就意味着df只是简单地错误了(并且实际上没有“丢失空间”的问题)。如果不能,那么du就是错误的(这将很有趣)。

我还没有找到这个问题的原因,但它只出现在Ubuntu 12.04上。
刚刚设置了一个新的服务器,我使用Ubuntu 12.04开始运行,遇到了这个问题;du显示大约111 GiB的使用量,而df则显示大约170 GiB。
使用systemrescuecd 3.3.0引导并再次检查后,显示的差异小于1 GiB。
保持分区和文件系统(ext4)不变,我将ubuntu目录移出,并安装了Debian 7.0。再次比较du和df的差异仍然小于1 GiB。
在相同的分区和ext4文件系统上,使用ubuntu 10.04:
df -m /
Filesystem           1M-blocks      Used Available Use% Mounted on
/dev/sda2              2814679    407164   2264538  16% /

du -mx命令中,
tail -1 /root/diskuse 
406920  .

足够接近。

你发布的图片告诉你空间的使用情况:/home/eric。看起来你在那里有一个非常大的文件占用了所有的空间,或者可能有很多较小的文件。打开你的主目录,确保显示隐藏文件(在Nautilus中按下Ctrl+H),并按文件大小排序。

你试过重新启动系统看看空间是否被回收了吗?
一个可能的情况是,如果你(或者你的系统)删除了占用大量空间的文件,但这些文件有一个打开的指针,直到所有指针关闭之前,磁盘空间将不会被回收,这就是为什么它“看起来”有空间,但实际上文件系统并不同意。如果你的磁盘空间用尽,文件系统将拒绝将更多文件写入磁盘,直到所有指针关闭。
并没有一种适用于所有情况的方法,真的是因情况而异,但在我遇到的一个情况中,syslog文件大小约为41GB,即使删除了它,空间也没有被回收,直到我关闭了一个持有它的进程,对我来说是Google Cloud Ops Agent Fluent-bit客户端。
在我的情况下,我使用了`$ lsof`命令找出哪个服务占用了它,然后使用`$ service`或`sudo systemctl restart [SERVICE_NAME]`命令。结果如预期。(另一种彻底的解决办法是重新启动,但那样太粗暴了)

垃圾桶中的文件通常会堵塞磁盘。使用“磁盘使用分析器”可以轻松找到它们。可以通过搜索“垃圾桶”来删除这些文件。还有一个选项可以删除“垃圾桶”的内容。还有一个选项可以删除“临时”文件。还可以设置选项以定期自动删除“垃圾桶”。