web-dev-qa-db-ja.com

dfコマンドは、ファイルを削除した後でも同じ使用率（100％）を示します

Nandフラッシュストレージパーティションは、dfコマンドで100％フルと表示されます。使用量を手動で計算すると、約7〜80％（最大）のみです。いくつかのファイルを削除しました（たとえば、約50〜60 MB）。それでも、dfコマンドの出力は変更されませんでした。新しいファイルを作成できません。エラー：「ストレージデバイスに空き容量がありません」。 syncコマンドを試しましたが、違いはありません。

Filesystem           1K-blocks      Used Available Use% Mounted on
tmpfs                   262144     20780    241364   8% /tmp
tmpfs                      512         0       512   0% /dev
/dev/ubi0_0            1275540   1275540         0  100% /storage

実際のストレージスペースがいっぱいではない場合（手動計算による）、なぜdoe dfコマンドは100％と表示するのですか？

linuxfilesystemsstorageflash-memory
2
Ravi

再起動して再マウントすれば、問題は解決すると思います。

理由：この背後にある理由は、dfがファイルシステムの統計情報を取得するためにシステムコール statfs（2） を利用することです。オープンカーネルファイルディスクリプタをチェックして、指定された空きスペースをカウントすることを意味します（df = disk free）。 duを使用すると、異なる結果が得られます。 dfは、ファイルが削除されたために100％使用されていることを示し、カーネルファイル記述子からまだ解放されていません。

次のscenerioを理解するのに役立ちます。

  1. xyz.serviceという名前の実行中のプロセスは、something.dumpパーティションにある/storageという名前のファイルを使用しています。

  2. file discriptorのsomething.dumpは、process file discriptor tableのxyz.serviceにリストされています。

  3. 次に、something.dumpを削除しましたが、xyz.serviceはまだ実行中です。

  4. xyz.serviceは、something.dumpファイルの更新されたsatusを認識していません。したがって、something.dumpのファイル記述子はまだ存在しています。

  5. 次に、dfコマンドを実行し、カーネルがすべてのプロセステーブルをチェックして、空き領域を計算するために使用されたファイル記述子を確認しました。

  6. カーネルは、something.dumpのfdがxyz.serviceプロセステーブルにあることを確認しました。したがって、something.dumpがまだファイルシステムにあるため、something.dumpのiノードが無料であるとは見なされません。これが、100％使用されている理由です。

  7. したがって、sigkill xyz.serviceすると、これらのiノードが解放され、確率で空きスペースを確認できます。

  8. システムを再起動すると、手順7と同じことが行われます。

2
muhammad