磁盘已满，du告诉不同。如何进一步调查？

我在服务器（硬件Raid 1），32G，ext3文件系统中有一个SCSI磁盘。df告诉我磁盘已满100％。如果删除1G，则可以正确显示。

但是，如果我运行a，du -h -x /则会du告诉我仅使用了12G（-x由于某些Samba安装，我使用了）。

因此，我的问题不是关于du和df命令之间的细微差异，而是关于我如何找出造成这种巨大差异的原因？

我重启了机器，发现没有错误的fsck。我应该跑步badblocks吗？lsof告诉我没有打开的已删除文件，lost+found为空，并且消息文件中没有明显的warn / err / fail语句。

随时询问设置的更多详细信息。

检查安装点下的文件。通常，如果将目录（例如sambafs）挂载到已在其下具有文件或目录的文件系统上，则会失去查看这些文件的能力，但它们仍会占用底层磁盘上的空间。在单用户模式下将文件转储到除单用户模式下看不到的目录中（由于其他目录系统已安装在它们之上），所以我有文件副本。

尝试在本地服务器上查找问题时，在该页面上偶然发现。

在我的情况下，df -h和du -sh不匹配，大约是硬盘大小的50％。

这是由于apache（httpd）将大型日志文件保留在已从磁盘删除的内存中引起的。

这是通过运行追查lsof | grep "/var" | grep deleted那里/var是我需要清理分区。

输出显示如下行：
httpd 32617 nobody 106w REG 9,4 1835222944 688166 /var/log/apache/awstats_log (deleted)

然后通过重新启动apache（service httpd restart）解决了这种情况，并通过清除已删除文件上的锁清除了2gb的磁盘空间。

我同意OldTroll的回答，这是造成您的“缺失”空间的最可能原因。

在Linux上，您可以轻松地将整个根分区（或与此相关的任何其他分区）重新挂载到文件系统中的另一个位置，例如说/ mnt，只需发出一个

mount -o bind / /mnt

那你可以做一个

du -h /mnt

看看是什么占用了您的空间。

附：抱歉，添加了新答案而不是评论，但我需要对本帖子进行一些格式设置才能使其可读。

看看怎么df -i说。可能是您没有inode，如果该文件系统中有大量小文件，则可能会发生这种情况，这会占用所有可用的inode而不占用所有可用空间。

就我而言，这与大型已删除文件有关。在找到此页面之前，解决起来非常痛苦，这使我走上了正确的道路。

我终于通过使用来解决了这个问题lsof | grep deleted，它向我显示了哪个程序保存着两个非常大的日志文件（总共8GB的可用根分区中有5GB）。

程序打开的文件实际上在删除时不会消失（停止消耗磁盘空间），而在程序关闭时消失。程序可能具有您（和du）看不到的巨大临时文件。如果它是僵尸程序，则可能需要重新启动以清除这些文件。

尝试执行以下操作，以查看死机/挂起进程是否仍在写入磁盘时被锁定：grep“ / mnt”

然后尝试清除所有卡住的PID（特别是寻找以“（已删除”）结尾的行）

迄今为止，这是我找到大文件的最简单方法！

这是一个示例，如果您的根挂载已满/（mount / root）示例：

cd /（因此您位于root用户中）

ls | xargs du -hs

示例输出：

 940万垃圾箱
 63M开机
 4.0K cgroup
 680K开发
 31M等
 6.3G家庭
 313M库
 32M lib64
 16K失物招领处
 61G媒体
 4.0百万
 选择1.13亿
 du：无法访问“ proc / 6102 / task / 6102 / fd / 4”：没有此类文件或目录
 0次
 19M根
 840K运行
 1900万条
 4.0K selinux
 4.0K srv
 25G商店
 26M转/分钟

那么您会发现store很大，执行 cd / store

再跑一次

ls | xargs du -hs

输出示例： 
 109M备份
 358M fnb
 4.0G iso
 8.0K ks
 16K失物招领处
 47M根
 1100万个脚本
 7900万首
 21G虚拟机

在这种情况下，vms目录是太空猪。

对我来说，我需要运行，sudo du因为/var/lib/docker非sudo用户没有读取权限，因此存在大量的docker文件。

需要考虑的另一种可能性-如果您使用的是docker，并且几乎可以肯定会看到一个很大的差异，并且在使用卷挂载的容器内运行df / du。如果目录已安装到Docker主机上的卷上，则df将报告主机的df总数。如果您考虑一下，这是显而易见的，但是当您收到“填充磁盘的容器失控！”的报告时，请确保使用诸如之类的方法来验证容器的文件空间消耗du -hs <dir>。

因此，我在Centos 7中也遇到了这个问题，并且尝试了很多类似bleachbit的东西并清理/ usr和/ var后找到了一个解决方案，即使它们每个都只显示了大约7G。仍显示根分区中使用了50G的50G，但仅显示了9G的文件使用率。运行一个实时ubuntu cd并卸载有问题的50G分区，打开终端，然后在该分区上运行xfs_check和xfs_repair。然后，我重新安装了该分区，并且我的lost + found目录已扩展到40G。按大小对丢失的内容和找到的内容进行排序，发现一个38G的蒸汽文本日志文件，最终只是重复出现mp3错误。删除了大文件，现在有了空间，我的磁盘使用与我的根分区大小一致。我仍然想知道如何使蒸汽记录不再变大。

如果装入的磁盘是Windows计算机上的共享文件夹，则df似乎会显示整个Windows磁盘的大小和磁盘使用情况，而du也会仅显示您有权访问的部分磁盘。（并已安装）。因此，在这种情况下，必须在Windows计算机上解决该问题。

生产中发生了类似的事情，磁盘使用率达到了98％。进行了以下调查：

a）df -i检查inode的使用情况，inode的使用率为6％，因此文件较小

b）挂载root并检查隐藏文件。无法归档任何多余的文件。du结果与安装前相同。

c）最后，检查nginx日志。它被配置为写入磁盘，但是开发人员直接删除了日志文件，从而nginx将所有日志保留在内存中。由于使用将该文件/var/log/nginx/access.log从磁盘上删除，因此使用时rm看不到du该文件，但是该文件已被存取nginx，因此仍保持打开状态

我有一个与本主题中提到的问题相同的问题，但是在一个VPS中。因此，我已经测试了本主题中描述的所有内容，但均未成功。该解决方案是与谁进行配额重新计算和修正的空间差异我们的VPS提供商的支持联系人df -h和du-sh /。

我今天在FreeBSD机器上遇到了这个问题。问题在于，这是一个工件vi（不是vim，不确定是否vim会造成此问题）。该文件正在占用空间，但尚未完全写入磁盘。

您可以使用以下方法进行检查：

$ fstat -f /path/to/mount/point |sort -nk8 |tail

这将查看所有打开的文件，并按-n第8列（键，-k8）对数字进行排序（通过），显示最后十个项目。

就我而言，最终（最大）条目如下所示：

bob      vi         12345    4 /var      97267 -rwx------  1569454080 rw

这意味着进程（PID）12345消耗了1.46G磁盘（第八列除以1024³），尽管没有du注意到它。 vi查看超大文件太可怕了；甚至100MB也足够。1.5G（或该文件实际有多大）是荒谬的。

解决方案是sudo kill -HUP 12345（如果不起作用，我会这样做sudo kill 12345，如果也失败了，那么可怕的kill -9事情就会发挥作用）。

避免在大文件上使用文本编辑器。快速浏览的示例解决方法：

假设合理的线长：

• { head -n1000 big.log; tail -n1000 big.log } |vim -R -
• wc -l big.log |awk -v n=2000 'NR==FNR{L=$1;next}FNR%int(L/n)==1' - big.log |vim -R -

假设不合理的大行：

• { head -c8000 big.log; tail -c8000 big.log } |vim -R -

vim -R在安装时，用它们代替view因为vim几乎总是更好。随意将它们插入view或vi -R代替。

如果要打开这么大的文件进行实际编辑，请考虑使用sed或awk其他编程方法。

检查您的服务器是否安装了ossec代理。或某些过程正在使用已删除的日志文件。在我以前是ossec代理。

检查/ lost + found，我有一个系统（centos 7），/ lost + found中的一些文件占用了所有空间。