我有一个服务器(硬件Raid 1),32G,ext3 filesytem SCSI磁盘。 df
告诉我,磁盘是100%满的。 如果我删除1G这是正确显示。
但是,如果我运行一个du -h -x /
那么du
告诉我只有12G被使用(因为一些Samba使用了-x
)。
所以我的问题不是关于du和df命令之间的细微差别,而是关于如何找出导致这种巨大差异的原因?
我重新启动了机器的fsck去了w / out错误。 我应该运行badblocks
吗? lsof
显示我没有打开删除的文件, lost+found
是空的,在消息文件中没有明显的warn / err / fail语句。
随意问一下设置的更多细节。
检查位于挂载点下的文件。 如果将一个目录(比如sambafs)挂载到一个已经有一个或多个目录的文件系统上,经常会失去查看这些文件的能力,但是它们仍然占用底层磁盘上的空间。 我已经在单用户模式转储文件中的文件拷贝到除了单用户模式(由于其他目录系统被安装在其上)之外我看不到的目录。
当试图追踪本地服务器上的问题时,偶然发现了这个页面。
在我的情况下, df -h
和du -sh
大约有50%的硬盘大小不匹配。
这是由apache(httpd)在内存中保存大量的日志文件引起的,这些文件已经从磁盘上删除了。
这是通过运行lsof | grep "/var" | grep deleted
追踪的 lsof | grep "/var" | grep deleted
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而不消耗所有的可用空间。
在我的情况下,这与大删除的文件。 在find这个页面之前解决起来相当痛苦,这使我走上了正确的道路。
我终于用lsof | grep deleted
解决了这个问题 lsof | grep deleted
,这显示了哪个程序拥有两个非常大的日志文件(总计5GB的可用8GB根分区)。
由程序打开的文件在删除时不会真正消失(停止使用磁盘空间),而在程序closures时它们会消失。 一个程序可能有一个巨大的临时文件,你(和)不能看到。 如果是僵尸程序,则可能需要重新启动以清除这些文件。
试试这个来看看是否仍然写入死/挂进程,同时仍然写入磁盘:lsof | grep“/ mnt”
然后尝试杀死任何卡住的PID(尤其是查找以“(已删除)”结尾的行)
这是我发现迄今为止find大文件的最简单的方法!
这里是一个例子,如果您的根挂载已满/(mount / root)示例:
CD / (所以你在根)
ls | xargs du -hs
输出示例:
9.4M bin 63M启动 4.0K cgroup 680K开发 31M等 6.3G的家 313M lib 32M lib64 16K输了+find了 61G媒体 4.0K mnt 113Mselect du:不能访问`proc / 6102 / task / 6102 / fd / 4':没有这样的文件或目录 0 proc 19M根 840K跑 19M sbin 4.0K selinux 4.0K srv 25G商店 26M tmp
那么你会注意到, 商店是大的做一个CD /商店
并再次运行
ls | xargs du -hs
示例输出: 109M备份 358M fnb 4.0G iso 8.0K ks 16K输了+find了 47M根 11M脚本 79M tmp 21G vms
在这种情况下,vms目录是空间猪。
所以我在Centos 7中也遇到了这个问题,并且在尝试了一些像bleachbit和清理/ usr和/ var之类的东西之后find了一个解决scheme,尽pipe它们每个只显示了大约7G。 仍然显示50G根分区中使用的50G,但只显示了9G的文件使用情况。 运行一个真正的Ubuntu的CD和卸载有问题的50G分区,打开terminal,并在分区上运行xfs_check和xfs_repair。 然后我重新安装了分区,我的lost + found目录已经扩展到了40G。 按大小sortingfind了丢失的+,发现一个38G文本日志文件的蒸汽,最终只是重复了一个MP3错误。 删除了大文件,现在有空间,我的磁盘使用量与我的根分区大小一致。 我仍然想知道如何让蒸汽日志不会再那么大。
如果挂载的磁盘是Windows机器上的共享文件夹,那么似乎df将显示整个Windows磁盘的大小和磁盘使用情况,但是du只会显示您有权访问的磁盘部分。 (并被安装)。 所以在这种情况下,问题必须固定在Windows机器上。
再考虑一个可能性 – 如果您使用的是docker,几乎可以保证看到一个很大的差异,并且在使用卷挂载的容器内运行df / du。 在docker主机上挂载一个目录的情况下,df将报告主机的df总数。 如果你仔细想想,这是显而易见的,但是当你得到一个“充满磁盘的失控容器!”的报告时,确保你用du -hs <dir>
这样的东西来validation容器的文件空间消耗。
检查/失去+find,我有一个系统(centos 7)和一些文件在/失去+find吃了所有的空间。