不可見的文件足跡（du vs df）

我知道du 和 df 將報告差異的預期原因，但是我無法想像這些可以證明我所看到的差異是合理的：

[root@example.com 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
[root@example.com mynfsmount]# du -sh /opt/mynfsmount
13G     /opt/mynfsmount

即 df 報告的使用量是 du 報告的約 300 倍。

NFS 伺服器是 Synology 機器，主機是 Centos 5.11（erk！）並且 /opt/mynfsmount 中沒有 lost+found 目錄，這可能很重要。這是我繼承的一個系統，幾乎沒有關於預計會有多少數據的資訊。

目前 lsof 僅報告一個已刪除的文件仍處於打開狀態。

我接下來要嘗試什麼的任何建議？

我認為這是預期的行為。

假設您有一個安裝了文件系統的伺服器，並且該文件系統/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磁碟。

引用自：https://unix.stackexchange.com/questions/527207