しばらく前に興味深い状況に直面しました。 /backup に 1TB NFS ファイルシステムがマウントされています。df報告された合計サイズは予想通り約1TBです。
ただし、du -csh ./backup/.snapshot ディレクトリで実行すると、3.0 TB のデータが報告されました。
私はduがマウントポイントより大きいフルサイズで出力を生成するのを見たことがありません。この NFS 共有は NetApp デバイスで提供されます。 .snapshotディレクトリはNetAppによって作成され、スペースの5％を使用するように構成されていることが知られています。 （もちろん、スペースを300％活用することは不可能です）
これはLinuxの問題ですか、NFSの問題ですか、NetAppの問題ですか、それとも別の問題ですか？他のどのデータを提供できますか？
オペレーティングシステムはCentOS 6です。
答え1
しばらくNetAppを使用していないため、絶対的な権限で回答することはできませんが、この種の動作の説明を提供できます。
LinuxのLVMのしくみと非常によく似ています。 LVMボリュームグループに100％マッピングされた1TBの物理ディスクがあるとします。これで、ボリュームグループに100 GBの論理ボリュームを作成します。いくつかのタスクを実行し、いくつかのファイルを配置するなどのタスクを実行します。次に、論理ボリュームのスナップショットを作成します。論理ボリュームで変更されたすべてのファイル（実際にはブロック）がコピーされるため、スナップショットから元のデータにアクセスできるようになりました。ただし、このスナップショットを撮って通常のボリュームのようにマウントすることもできます。マウントすると、2つの100 GBファイルシステムがマウントされます。ただし、両方のファイルシステムは、ファイルシステムの1つのデータが変更されるまで同じデータ（物理ボリュームブロック）を共有します。
したがって、NetAppができることは、/backup/.snapshotカタログを介してこれらのスナップショットへのアクセスを提供することです。分析の結果、各スナップショットは元のボリュームと同じサイズで表示されます。
奇妙に思えるかもしれませんが（NFS、カーネルなどについて）、完全に正当です。を実行すると、dfシステムは「このファイルシステムのサイズ」を知らせるNFS呼び出しを実行し、リモートシステムは必要に応じて応答できます。その後、duシステムは「このファイルのサイズ」を知らせるNFS呼び出しを実行し、リモートシステムは必要に応じて応答できます。
スパースファイルに対して同様の（同じではない）操作を実行することもできます。ファイルは実際よりも多くのスペースを占めているそうです。
今日では、ファイルシステムのスペースを節約する高度な方法がたくさんあります。 「私が持っているスペースはどれくらいですか？」あるいは、「このファイルが占めるスペースはどれくらいですか？」という質問に必ずしも簡単な答えがあるわけではありません。スナップショット、重複排除、透明な圧縮などを使用できます。