it-swarm.cn

du与df之差

我有一个文件服务器,其中df报告了94%的/已满。但是根据du,使用的更少了:

# df -h /
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda3             270G  240G   17G  94% /
# du -hxs /
124G    /

我读到打开但已删除的文件可能是造成此问题的原因,但是重新启动无法解决此问题。

这是Linux,ext3。

问候

33
Andreas Kuntzagk

好,找到了。

我在/ mnt/Backup 在同一文件系统中中有一个旧备份,然后在该位置安装了一个外部驱动器。所以du没有看到文件。因此清理此磁盘后,我得到了磁盘空间。

可能是这样发生的:在每日备份脚本运行时,曾经卸下了外部驱动器。

32
Andreas Kuntzagk

我不认为您会找到更详尽的解释,然后 此链接 可能会关闭。一些重点可能会有所帮助:

  • 您的inode用法是什么,如果几乎100%会使事情搞砸:

    df -i

  • 您的块大小是多少?许多小文件和大块文件可能会使它有些偏斜。

    须藤tune2fs -l/dev/sda1 | grep'块大小'

  • 删除的文件,您说您已调查过,但是要获得总空间,您可以使用以下管道(我喜欢使用find代替lsof,因为lsof很难解析):

    Sudo查找/ proc/*/fd -printf“%l\t%s\n” | grep已删除|切-f2 | (tr'\ n'+;回声0)|公元前

但是,这几乎减少了2倍。为了安全起见,请在分区上运行fsck

18
Kyle Brandt

看起来好像是文件被删除而进程仍将其打开的情况。之所以发生这种断开连接,是因为du命令总计了文件系统中存在的文件的空间,而df显示了文件系统中可用的块。在关闭该文件之前,不会释放已打开和已删除文件的块。

您可以通过检查/ proc来查找哪些进程已打开但已删除文件

find /proc/*/fd -ls | grep deleted
11
TCampbell

在这种情况下,最可能的原因是您有很多非常小的文件(小于驱动器上的块大小)。在这种情况下,df将报告所有已用块的总和,而du将报告文件大小的实际总和。

8
wolfgangsz

我同意

lsof +L 1 /home | grep -i deleted

这是一个很好的起点,就我而言,我注意到我有很多正在运行的Perl脚本,并且即使应该删除许多文件,它们也仍然处于活动状态。

我杀死了Perl函数,这使dudf几乎相同,但不区分大小写。

7
Sverre

默认情况下,当您使用EXT3格式化文件系统时,5%的驱动器保留用于root用户。 df会在报告可用资源时考虑此储备金,而du则会显示实际使用的资源。

您可以通过运行以下命令查看保留的块:

tune2fs -l/dev/sda | grep -i保留

你会得到类似的东西:

Reserved block count:     412825
Reserved GDT blocks:      1022
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)

如果您想将其调整为较低的百分比,可以使用类似的方法

tune2fs -m 1/dev/sda

您可以将其减小为0,但是由于这是您的根文件系统,因此我对此会有所警惕。如果文件系统实际已填满,可能会使清除它所需的维护任务变得困难。

1
Alex

可能du也不会增加目录的大小吗?尽管如此,这似乎是一个巨大的差异,但这并不是全部原因。

0
Brian Knoblauch