df告诉我磁盘已满100％。如果我删除1G，则可以正确显示。但是，如果我运行
du -h -x /，则du告诉我仅使用了12G（由于使用了一些Samba安装，我使用-x）。所以我的问题不是关于du和df命令之间的细微差别，而是关于我如何找出造成这种巨大差异的原因？
我重新启动了机器，发现fsck出现错误。我应该运行
badblocks吗？ lsof显示没有打开的已删除文件，lost+found是空的，并且消息文件中没有明显的warn / err / fail语句。请随时询问设置的更多详细信息。
#1 楼
检查安装点下的文件。通常，如果将目录（例如sambafs）挂载到已在其下具有文件或目录的文件系统上，则会失去查看这些文件的能力，但它们仍会占用底层磁盘上的空间。在单用户模式下，我有文件副本，但是将文件转储到单用户模式下看不到的目录中（由于其他目录系统已安装在它们之上）。评论
您可以找到这些隐藏文件，而无需卸载目录。看看下面的Marcel G答案，它解释了如何。
– mhsekhavat
17年7月23日在7:39
您应该在答案中显示CLI命令来执行此操作
–乔纳森
18-10-10在17:26
即使您认为这对您没有意义，也要进行检查！
–克里斯
18-10-26在14:32
注意：此答案是关于位于安装点下方（即隐藏在原始文件系统上）而不是位于安装点内的文件的。 （别像我这样的白痴。）
–mwfearnley
18年11月27日在15:18
#2 楼
尝试在本地服务器上查找问题时，偶然发现了此页面。在我的情况下，
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的磁盘空间，允许对已删除文件进行锁定被清除。评论
对我来说，即使我停止了程序，锁也没有释放（僵尸？）。我必须杀死-9'pid'才能释放锁。例如：对于您的httpd，它将被杀死-9 32617。
– Micka
15年6月17日在8:57
小注释：您可能必须以sudo的身份运行lsof，否则并非所有打开的文件描述符都将显示
– ChristWue
16年8月8日，下午1:34
我遇到了H2，它每天都在日志文件中添加几个演出。而不是重新启动H2（缓慢），我使用了sudo truncate -s0 / proc /（h2 PID）/（从ls / proc / h2pid / fd获得的描述符编号）。
– Desty
16-09-26在14:57
就我而言，即使重启httpd空间也没有释放。当我运行/etc/init.d/rsyslog重新启动时，它工作：D
– Thanh Nguyen Van
16-9-29 at 1:11
您可以跳过这一步，只需执行lsof -a + L1 / var，其中-a表示所有条件（所有条件）（默认为OR），+ L1表示仅列出链接计数小于1的文件（即，已删除的文件带有打开的文件描述符） ）和/ var约束到该安装点下的文件
– kbolino
18年5月13日在2:50
#3 楼
我同意OldTroll的回答是造成“丢失”空间的最可能原因。在Linux上，您可以轻松地将整个根分区（或与此相关的任何其他分区）重新安装到文件系统中的另一个位置。例如说/ mnt，只需发出一个
mount -o bind / /mnt
，然后您就可以执行一个
du -h /mnt
并查看
Ps：很抱歉添加新答案而不是发表评论，但我需要对本帖子进行一些格式设置才能使其可读。
评论
非常感谢您的提示。允许我查找和删除大型“隐藏”文件，而无需停机！
–加法
13年2月28日在13:47
谢谢-这表明docker用/ var / lib / docker / aufs / diff /中的差异填充了我的硬盘
–naught101
2015年8月5日，下午3:29
mount -o bind / / mnt提供了我正在寻找的其他信息。谢谢！
–Slavik Meltser
19-10-20在14:10
谢谢！通过这些命令，我设法找到导致磁盘使用率提高10％的原因并将其释放。仅列出我使用的最大文件夹和文件du / mnt |排序-n -r |头-20
–refex
20-04-21在10:51
想要添加此功能有助于在尚未及时装入文件夹但又写入了另一个进程的地方。最初，我从du命令中隐藏了OMV的/ sharedfolders，以便更轻松地进行查询，结果发现其中的文件夹导致了我的问题，谢谢。
–丹·克拉克（Dan Clarke）
20'八月20'在9:39
#4 楼
看看df -i怎么说。可能是您没有inode，如果该文件系统中有大量小文件，则可能会发生这种情况，这会占用所有可用的inode而不占用所有可用空间。评论
文件的大小和在文件系统上占用的空间量是两件事。文件越小，它们之间的差异越大。如果编写一个脚本来汇总文件的大小并将其与同一子树的du -s进行比较，那么在这种情况下，您将有一个好主意。
–马辛
2011年5月30日15:00
#5 楼
就我而言，这与删除的大型文件有关。在找到此页面之前，解决起来非常痛苦，该页面将我设置在正确的路径上。我最终使用
lsof | grep deleted解决了该问题，该页面显示了哪个程序保存着两个非常大的日志文件（我的可用8GB根分区中总共有5GB）。评论
这个答案让我感到奇怪，为什么您要在根分区上存储日志文件，尤其是这么小的日志文件...但是我想对于每个文件...
–用户
2014年11月14日18:47
我有一个类似的问题，我已经重新启动了所有使用已删除文件的应用程序，我想仍然有一个僵尸进程正在保留一个较大的已删除文件
–user1965449
2015年12月15日在2:37
对我们来说就是这种情况，一个名为filebeat的日志处理Linux应用程序使文件保持打开状态。
–派克勒
16 Dec 7'在20:53
@Pykler对我们来说，它也是文件拍。谢谢你的提示！
–马丁·海默斯（Martijn Heemels）
19年1月29日在9:30
#6 楼
程序打开的文件实际上在删除时不会消失（停止消耗磁盘空间），而在程序关闭时消失。程序可能包含您（和du）看不到的巨大临时文件。如果它是僵尸程序，则可能需要重新启动以清除这些文件。评论
OP说他重新启动了系统，问题仍然存在。
–OldTroll
2011年5月30日12:58
我遇到了无法释放文件锁的僵尸，我杀死了-9'pid'来释放锁并获取磁盘空间。
– Micka
15年6月17日在8:58
#7 楼
对我来说，我需要运行sudo du，因为在/var/lib/docker下有大量的docker文件，非sudo用户没有读取权限。评论
这是我的问题。我忘记了在docker中切换存储系统，而旧卷仍在徘徊。
–理查德·尼纳伯（Richard Nienaber）
19年1月9日在9:21
我有同样的问题，谢谢。这对我有帮助：docker system prune -a -f;泊坞窗卷rm $（泊坞窗卷ls -qf dangling = true）
– mnicky
19/12/8在15:48
#8 楼
尝试执行以下操作，以查看死机/挂起进程是否仍在写入磁盘时被锁定：lsof | grep“ / mnt”
然后尝试清除所有卡住的PID（尤其是查找以“（deleted”）结尾的行）
评论
谢谢！我能够发现SFTP服务器进程正在保存已删除的文件
– lyomi
13年8月30日在4:43
#9 楼
这是迄今为止我发现的查找大文件的最简单方法！这里是一个示例，说明您的根装载已满/（mount / root）
示例：
< br cd /（所以您是root用户）
ls | xargs du -hs
示例输出：
9.4M bin 63M boot 4.0K cgroup 680K dev 31M etc 6.3G home 313M lib 32M lib64 16K lost+found 61G media 4.0K mnt 113M opt du: cannot access `proc/6102/task/6102/fd/4': No such file or directory 0 proc 19M root 840K run 19M sbin 4.0K selinux 4.0K srv 25G store 26M tmp
然后您会发现存储很大，请执行
cd / store
，然后再次运行
ls | xargs du -hs
Example output: 109M backup 358M fnb 4.0G iso 8.0K ks 16K lost+found 47M root 11M scripts 79M tmp 21G vms
在这种情况下，vms目录是太空猪。
评论
为什么不使用像猴面包树这样的简单工具呢？ （请参阅marzocca.net/linux/baobab/baobab-getting-started.html）
–伊万
2015年5月5日7:11
嗯ls + xargs似乎有点过头了，du -sh / *本身就可以正常工作
– ChristWue
16年8月8日在1:35
如果您不了解ncdu，请稍后再感谢我：dev.yorhel.nl/ncdu
–特洛伊·佛尔格（Troy Folger）
16 Dec 5'在22:56
#10 楼
需要考虑的另一种可能性-如果您使用的是docker，并且几乎可以肯定会看到一个很大的差异，并且在使用卷挂载的容器内运行df / du。如果目录已安装到Docker主机上的卷上，则df将报告主机的df总数。如果考虑一下，这是显而易见的，但是当您收到“填充磁盘的容器失控！”的报告时，请确保使用诸如du -hs <dir>之类的东西来验证容器的文件空间消耗。#11 楼
因此，我在Centos 7中也遇到了这个问题，并尝试了很多类似bleachbit的工作，并清理了/ usr和/ var，即使它们每个仅显示约7G，也找到了解决方案。仍显示根分区中使用了50G的50G，但仅显示了9G的文件使用率。运行一个实时ubuntu cd并卸载有问题的50G分区，打开终端，然后在该分区上运行xfs_check和xfs_repair。然后，我重新安装了该分区，并且我的lost + found目录已扩展到40G。按照大小对丢失的内容和找到的内容进行排序，找到了一个38G的文本日志文件，该文件最终只是重复出现了mp3错误。删除了大文件，现在有了空间，我的磁盘使用与我的根分区大小一致。我仍然想知道如何使蒸汽记录不再变大。评论
这是在工作中发生的吗？ serverfault.com/help/on-topic
–小鸡
17年5月4日在20:37
不只是在我的家用计算机上。
–贾斯汀·查德威克（Justin Chadwick）
17年5月6日，下午2:57
xfs_fsr为我们解决了这个问题
–德鲁斯卡
17年8月17日在18:34
#12 楼
如果装入的磁盘是Windows计算机上的共享文件夹，则df似乎会显示整个Windows磁盘的大小和磁盘使用情况，但是du也会仅显示您有权访问的部分磁盘。 （并已安装）。因此在这种情况下，必须在Windows计算机上解决该问题。#13 楼
生产中发生了类似的事情，磁盘使用率达到了98％。进行了以下调查：a）检查inode的使用情况
df -i，inode的使用情况为6％，因此较小的文件没有很多b）安装
root并检查隐藏文件。无法归档任何多余的文件。 du结果与安装前相同。c）最后，检查
nginx日志。它被配置为写入磁盘，但是开发人员删除了日志文件，直接导致nginx将所有日志保留在内存中。由于使用/var/log/nginx/access.log从磁盘上删除了文件rm，因此使用du看不见文件，但是文件被nginx访问，因此仍然保持打开状态#14 楼
我遇到了与该主题中提到的问题相同的问题，但是在一个VPS中。因此，我已经测试了该主题中描述的所有内容，但均未成功。
解决方案是与我们的VPS提供商联系以寻求支持，该提供商执行配额重新计算并更正了
df -h和du-sh /的空间差异。#15 楼
我今天在FreeBSD机器上遇到了这个问题。问题是它是vi的工件（不是vim，不确定vim是否会造成此问题）。该文件正在占用空间，但尚未完全写入磁盘。您可以使用以下命令进行检查：
$ fstat -f /path/to/mount/point |sort -nk8 |tail
打开文件并按第8列（键，
-n）排序（通过q4312079q进行数字排序），显示最后十个项目。对于我来说，最后一个（最大）条目看起来像这样：
bob vi 12345 4 /var 97267 -rwx------ 1569454080 rw
这意味着进程（PID）12345消耗了1.46G磁盘（第八列除以1024³），尽管没有
-k8注意到它。 du在查看超大文件时令人恐惧；甚至100MB也足够。 1.5G（或文件的实际大小太大）太可笑了。解决方法是
vi（如果不起作用，我会选择sudo kill -HUP 12345，如果它也失败了，那可怕的sudo kill 12345就会来了发挥作用。）避免在大文件上使用文本编辑器。快速浏览的示例解决方法：
假定合理的行长：
kill -9 { head -n1000 big.log; tail -n1000 big.log } |vim -R - 假定行不合理（ s）：
wc -l big.log |awk -v n=2000 'NR==FNR{L=;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或其他编程方法。#16 楼
检查您的服务器是否安装了ossec代理。或某些进程正在使用已删除的日志文件。在我以前是ossec代理。评论
OP提到机器已重新启动，因此应该没有删除的文件了。
– RalfFriedl
19 Mar 5 '19 at 18:06
#17 楼
就我而言，lsof没有帮助。之所以能够对此进行跟踪，是因为我已经使用Lostup作为循环设备挂载了磁盘映像。即使卸载了这些设备并删除了相应的映像之后，仍有一些进程维护了对磁盘映像的某种间接引用。总之，
sudo ps -ef|grep loop然后sudo losetup -d /dev/loopX。这不是du和df为何不同意的直接答案，但对我而言它经常出现，我终于能够弄清为什么它与我能找到的任何答案都不一样的原因。#18 楼
检查/ lost + found，我有一个系统（centos 7），/ lost + found中的一些文件占用了所有空间。评论
如问题所述，这将如何解释报告的磁盘使用情况的差异？
–roaima
16-11-30在23:36
评论
这与问题非常接近：linux-du vs. df的区别（serverfault.com/questions/57098/du-vs-df-difference）。解决方案是将文件放在OldTroll回答的挂载点下。