题 盘满,杜说不同。如何进一步调查?


我在服务器(硬件Raid 1),32G,ext3 filesytem中有一个SCSI磁盘。 df 告诉我磁盘已满100%。如果我删除1G,则会正确显示。

但是,如果我跑了 du -h -x / 然后 du 告诉我只使用12G(我使用 -x 因为一些Samba坐骑)。

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

我重新启动机器以获得没有错误的fsck。我该跑吗? badblockslsof 告诉我没有打开已删除的文件, lost+found 为空,消息文件中没有明显的warn / err / fail语句。

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


89
2018-05-30 12:29




这非常接近这个问题:linux - du vs. df difference(serverfault.com/questions/57098/du-vs-df-difference)。当OldTroll回答时,解决方案是挂载点下的文件。 - Chris Ting


答案:


检查位于挂载点下的文件。通常,如果将目录(例如sambafs)挂载到已经有一个或多个文件的文件系统上,您将无法查看这些文件,但它们仍然在底层磁盘上占用空间。我在单用户模式下将文件转储到我无法看到的目录中的文件副本,除了单个用户模式(由于其他目录系统安装在它们之上)。


87
2018-05-30 12:35



您可以找到这些隐藏文件,而无需卸载目录。看看下面Marcel G的答案,它解释了如何解释。 - mhsekhavat
您应该在答案中显示CLI命令来执行此操作 - Jonathan
即使你认为它对你没有意义,也要检查! - Chris


在尝试追踪本地服务器上的问题时,偶然发现了这个页面。

在我的情况下 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磁盘空间。


71
2018-03-12 11:10



对我来说,即使在我停止程序(僵尸?)之后,锁还没有被释放。我不得不 kill -9 'pid' 释放锁。例如:对于你的httpd,它本来就是 kill -9 32617。 - Micka
次要说明:您可能需要运行 lsof 如 sudo 或不是所有打开的文件描述符都会出现 - ChrisWue
我遇到了H2,它每天都会在日志文件中添加几个演出。我没有重新启动H2(慢),而是使用了 sudo truncate -s0 /proc/(h2 PID)/(descriptor number obtained from ls /proc/h2pid/fd)。 - Desty
在我的情况下,即使重新启动 httpd 空间没有释放。当我跑 /etc/init.d/rsyslog restart 它起作用了:D - Thanh Nguyen Van
你可以跳过greps,就这样做 lsof -a +L1 /var,哪里 -a 表示AND所有条件(默认为OR), +L1表示仅列出链接计数小于1的文件(即,具有打开文件描述符的已删除文件),以及 /var 约束到该挂载点下的文件 - kbolino


我同意OldTroll的答案是您“失踪”空间的最可能原因。

在Linux上,您可以轻松地将整个根分区(或任何其他分区)重新安装到您文件系统中的另一个地方,例如/ mnt,只需发出一个

mount -o bind / /mnt

然后你可以做一个

du -h /mnt

并看看你的空间用尽了什么。

Ps:抱歉添加新答案而不是评论,但我需要一些格式化这篇文章才能阅读。


40
2018-05-30 13:54



非常感谢这个提示。允许我在没有停机的情况下找到并删除我的大型“隐藏”文件! - choover
谢谢 - 这表明docker正在填充我的硬盘驱动器 /var/lib/docker/aufs/diff/ - naught101


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


23
2018-05-30 14:10



文件大小和文件系统占用的空间量是两个不同的东西。文件越小,它们之间的差异就越大。如果你编写一个脚本来总结文件的大小并将其与文件进行比较 du -s 在同一个子树中,如果是这种情况,你会得到一个好主意。 - Marcin


在我的情况下,这与大型删除文件有关。在我找到这个页面之前解决起来相当痛苦,这让我走上了正确的道路。

我终于通过使用解决了这个问题 lsof | grep deleted,它向我展示了哪个程序包含两个非常大的日志文件(总共5GB的可用8GB根分区)。


15
2017-11-14 18:15



这个答案让我想知道你为什么要在根分区上存储日志文件,特别是那个小的......但是对于每个人来说,我想... - α CVn
我有一个类似的问题,我已经重新启动了所有使用已删除文件的应用程序,我猜有一个僵尸进程仍然持有一个大的已删除文件 - user1965449
这就是我们的情况,一个日志处理linux应用程序称为filebeat保持文件打开。 - Pykler


程序打开的文件在删除时实际上不会消失(停止消耗磁盘空间),当程序关闭它们时它们会消失。程序可能有一个巨大的临时文件,您(和du)无法看到。如果它是僵尸程序,您可能需要重新启动才能清除这些文件。


5
2018-05-30 12:51



OP说他重新启动了系统并且问题仍然存在。 - OldTroll
我有僵尸,不会释放文件上的锁,我 kill -9 'pid' 他们释放锁并获得磁盘空间。 - Micka


这是迄今为止我发现找到大文件的最简单的方法!

以下是根安装已满/(mount / root)的示例 例:

cd / (所以你是根)

ls | xargs du -hs

示例输出:

 9.4M箱
 63M开机
 4.0K cgroup
 680K开发
 31M等
 6.3G回家
 313M lib
 32M lib64
 16K丢失+找到
 61G媒体
 4.0K mnt
 113M选择
 du:无法访问`proc / 6102 / task / 6102 / fd / 4':没有这样的文件或目录
 0 proc
 19M根
 840K运行
 19M sbin
 4.0K selinux
 4.0K srv
 25G店
 26M tmp

那你会注意到的 商店 做得很大 cd / store

并再次运行

ls | xargs du -hs

输出示例:
 109M备份
 358M fnb
 4.0G iso
 8.0K ks
 16K丢失+找到
 47M根
 11M脚本
 79M tmp
 21G vms

在这种情况下,vms目录是空间占用。


4
2018-06-26 13:05



为什么不使用更简单的工具 baobab? (看到 marzocca.net/linux/baobab/baobab-getting-started.html) - Yvan
HM ls + xargs 看起来有点矫枉过正, du -sh /* 单独工作就好了 - ChrisWue
如果你不知道ncdu ......你以后会感谢我的: dev.yorhel.nl/ncdu - Troy Folger


尝试此操作以查看在写入磁盘时是否锁定了死/挂进程: lsof | grep“/ mnt”

然后尝试消除任何卡住的PID(特别是查找以“(已删除”)结尾的行)


3
2018-06-26 10:38



谢谢!我能够发现SFTP服务器进程正在保存已删除的文件 - lyomi


所以我在Centos 7中也遇到了这个问题,并在尝试了一些像漂白剂和清洁/ usr和/ var这样的东西之后找到了解决方案,尽管它们每个只显示了大约7G。仍然显示在根分区中使用的50G 50G但仅显示9G的文件使用情况。运行一个实时的ubuntu cd并卸载有问题的50G分区,打开终端并在分区上运行xfs_check和xfs_repair。然后我重新安装了分区,我丢失的+找到的目录已扩展到40G。按大小排序丢失+找到并找到一个38G文本日志文件的蒸汽,最终只是重复一个mp3错误。删除了大文件,现在有空间,我的磁盘使用率与我的根分区大小一致。我仍然想知道如何让蒸汽记录再次变得不那么大。


1
2018-05-04 18:01



工作中发生了这件事吗? serverfault.com/help/on-topic - chicks
不只是在我的家用电脑上。 - Justin Chadwick
xfs_fsr 为我们解决了这个问题 - Druska