主页 / unix / 问题 / 527207
Accepted
symcbean
Asked: 2019-06-28 01:53:02 +0800 CST

不可见的文件足迹（du vs df）

  • 772

我知道du 和 df 将报告差异的预期原因，但是我无法想象这些可以证明我看到的差异是合理的：

[[email protected] mynfsmount]# df -h /opt/mynfsmount
Filesystem            Size  Used Avail Use% Mounted on
192.168.0.92:/data/export/examplecom
                      3.0T  2.7T  391G  88% /opt/mynfsmount
[[email protected] mynfsmount]# du -sh /opt/mynfsmount
13G     /opt/mynfsmount

即 df 报告的使用量是 du 报告的约 300 倍。

NFS 服务器是 Synology 机器，主机是 Centos 5.11（erk！）并且 /opt/mynfsmount 中没有 lost+found 目录，这可能很重要。这是我继承的一个系统，几乎没有关于预计会有多少数据的信息。

目前 lsof 仅报告一个已删除的文件仍处于打开状态。

我接下来要尝试什么的任何建议？

files nfs

1 个回答

  1. Best Answer

    我认为这是预期的行为。

    假设您有一个安装了文件系统的服务器，并且该文件系统/foo包含两个目录bar并baz为您提供/foo/bar/和/foo/baz/. 让我们说：

    • /foo是一个 100GB 的文件系统
    • /foo/bar/包含 10GB 的文件
    • /foo/baz/包含 20GB 的文件
    • 剩余 70GB 可用空间。

    如果然后/foo/bar通过 NFS 导出。并将其作为/mnt/bar. 然后在你执行的 clint 上：

    df -h /mnt/bar
du -hs /mnt/bar

    我希望：

    • df显示已用 30GB，免费 70GB，总共 100GB。
    • du显示仅使用了 10GB。

    其他 20GB 没有通过 NFS 暴露，但在df. 这是大多数操作系统上远程文件系统协议的正常行为。

    简而言之，df显示安装在远程服务器上的整个文件系统的统计信息。 du显示您有权访问的文件的总大小。

    注意：还有许多其他原因du可能无法访问文件系统中包含的某些文件。其他几个原因包括：

    • 可以在程序仍在写入文件时删除（取消链接）文件。如果发生这种情况，文件将保留在磁盘上，直到删除所有引用（包括打开的文件句柄）。 du找不到这些，因为它们没有文件名。但是它们仍然会有一个 inode，因此在检查时仍然会显示df.
    • 同样，文件系统有时可能会损坏。由于损坏而关闭所有引用后，文件仍然存在。这是对磁盘执行半定期fsck检查的一个很好的理由。

    到目前为止，您的场景中最有可能的是我在顶部显示的导出示例。但是，如果您担心，请卸载和fsck磁盘。

    • 1

相关问题