わかりました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システムに2つのディレクトリがありますbar。それは言うことができます：baz/foo/bar//foo/baz/
/foo100GBファイルシステムです/foo/bar/10GBファイルを含む/foo/baz/20GBファイルを含む- これで70GBの空き容量が残ります。
次に、/foo/barNFS経由でエクスポートします。次に、clint/mnt/barで次の2つのことを行います。
df -h /mnt/bar
du -hs /mnt/bar
私は期待:
df30GB使用、70GB使用可能、合計100GBが表示されます。du10 GB のみ使用されたとマークされます。
残りの 20 GB はまだ NFS を通じて公開されていませんが、dfこれはほとんどのオペレーティングシステムでリモートファイルシステムプロトコルの正常な動作です。
つまり、dfリモートサーバーにマウントされたファイルシステム全体の統計を表示します。 duアクセスできるファイルの合計サイズを表示します。
メモ:duファイルシステムに含まれる特定のファイルにアクセスできないには、他にも多くの理由があります。他の理由は次のとおりです。
- 削除できます（解く）プログラムがまだファイルに書き込んでいる間。これが発生すると、ファイルはすべての参照（開いたファイルハンドルを含む）が削除されるまでディスクに残ります。
duファイル名がないため見つかりません。ただし、インデックスノードがまだ存在しているため、を使用してチェックしても表示されますdf。 - 同様に、ファイルシステムも時々破損します。破損が原因ですべての参照が閉じられても、ファイルは存在し続けることがあります。これが反定期的に訓練する良い理由です。FSCKディスクを確認してください。
あなたのシナリオで最も可能性が高いのは、私が一番上に示したエクスポートの例です。しかし、心配な場合は、fsckディスクをアンマウントしてください。