ファイルの削除

ファイルの削除は二つの処理から成り立つ。

ディレクトリエントリからの登録削除
ファイル実体(ファイルを構成するiノードとデータブロック)の解放

ディレクトリエントリからの登録削除処理は、unlinkシステムコールにおいて行う。ファイルを構成するiノードとデータブロックの解放は、そのファイルへの参照が無くなった時点で行われる(iput関数の延長)。通常はunlinkシステムコールと同時に、どこのディレクトリからも登録されておらず、どのプロセスからも参照されていない状態になるため、ほとんどの場合この二つの処理は同時に行われる。

open中のファイルの削除を行った場合は、unlinkシステムコール上ではファイル実体解放は行われず、closeシステムコールの延長でファイル実体の解放が行われることとなる。

unlinkシステムコールは、vfs sys_unlink(do_unlink)関数においてこれから削除するファイルのdentryを求めた後、親ディレクトリのiノードのunlinkオペレーションを呼び出すことにより実現されている。ext2ファイルシステムの場合は、 ext2_unlink関数が呼び出される。ext2_unlink関数はディレクトリエントリから目的のエントリを消した後、d_delete関数を呼び出す。

  ext2_unlink(親ディレクトリのiノード, 削除するファイルのdentry)
      削除するディレクトリエントリを検索(ext2_find_entry関数)
      ディレクトリエントリを削除(ext2_delete_entry関数)
      親ディレクトリのiノードの更新時間変更
      ◇親ディレクトリiノードの遅延書き込み要求(mark_inode_dirty関数)
      削除するファイルのiノードのリンク数を1減らす
      ◇削除するファイルのiノードの遅延書き込み要求(mark_inode_dirty関数)

ファイル実体の削除処理はiput関数が行っている。通常はd_delete関数の処理(vfsが呼び出す)の延長で呼び出され、ファイル本体の解放が行われる。(d_delete関数 → dentry_iput関数 → iput関数)一方open中のファイルの場合は、closeシステムコールから呼び出されるdput関数を通してiput関数がが呼び出される。(dput関数 → dentry_iput関数 → iput関数)iput関数は対象のファイルの参照カウントとリンクカウントが共に0となるとそのスーパブロックに登録されているdelete_inodeオペレーションを呼び出す。

ext2ファイルシステムでは、delete_inodeオペレーションは以下の関数である。

  ext2_delete_inode(iノード)
      iノードに削除時刻を設定(i_dtimeメンバ)
      ◇iノードの遅延書き込み要求(mark_inode_dirty関数)
      ◆iノードを書き込む(ext2_update_inode関数)
      iノード情報のファイルサイズを0にする(i_sizeメンバ)
      if(iノードにデータブロックが登録されていれば(i_blocksメンバ) ) {
             登録されている全てのブロックの解放を行う(ext2_truncate関数)
      }
      iノードの解放を行う(ext2_free_inode関数)

問題点、捕捉

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

(NIS)HirokazuTakahashi
2000年12月09日 (土) 23時55分06秒 JST1

Up: 各種システムコールアルゴリズム

Prev: ファイルの生成

Next: トランケートシステムコール