問題点

  1. SYNCモードでマウントしている場合、 解放するiノード情報まで同期書き込みしており、性能上不利である。 また同期書き込みしているデータは、データブロック解放前の 状態であり、次回のファイル生成時に初期化がさぼれるという訳でもない。
  2. d_delete処理でdentryをキャッシュから外す処理が抜けているため、 unlinkシステムコール出口のdput()でdentryが解放されず、カーネル中に ゴミとして溜まっていく。 unlink本体処理ではdentryをキャッシュから外す処理のみとし、 unlinkシステムコール出口のdputでiノードの解放から、dentryの解放まで 行った方が良さそうに思える。
  3. unlinkする対象がリンクされているファイルの場合、リンク数が 0にならないため、iノードの解放ルーチンは呼び出されない。 ただし、削除するファイルのiノードのリンク数を1減らす処理は、 遅延書き込みとして実現されているため、このタイミングでシステムが クラッシュすると、実際にディレクトリに登録されている数より iノードのリンク数の方が多いファイルができてしまう。 これはfsckで簡単に修復可能。 もしfsckを行わずに運用した場合でも、このファイルの削除時に 浮きブロックとなるだけであり、ファイルシステム構造破壊には 継らない。
  4. unlink処理時、リンク数(i_nlink)が0になっていると warningメッセージを出し、強制的にリンク数を1にして 処理を継続している。ファイルシステムが壊れている場合の 処理であるが、二重解放される危険がある。

(NIS)HirokazuTakahashi
2000年06月11日 (日) 22時29分57秒 JST
1