我知道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 仅报告单个已删除文件仍处于打开状态。
我下一步尝试什么有什么建议吗？
答案1
我认为这是预期的行为。
假设您有一台安装有文件系统的服务器，/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找不到这些，因为它们没有文件名。但它们仍然会有一个索引节点，因此在使用 进行检查时仍然会显示df。 - 同样，文件系统有时也会损坏。由于损坏而关闭所有引用后，文件仍然可以存在。这是进行半定期训练的一个很好的理由FSCK检查您的磁盘。
到目前为止，您的场景中最有可能的是我在顶部显示的导出示例。但如果您担心，请卸载fsck磁盘。