internal24-113-問題点など - Linux Kernel Documents Wiki - Linux Kernel Documents

問題点など

1. 上記ディスクiノード確保アルゴリズムの問題点は、 syncモードのmountであっても新規作成したiノードの 同期書き込みが行われていない点にある。 iノードの書き込み前に、このiノードがディレクトリに 登録された場合、一時的にディスク上のデータ構造に矛盾が生じる。 このタイミングでシステムがクラッシュするとDUPブロックが 発生する可能性がある。
2. メモリ上のスーパブロック内にブロックグループのビットマップ (iノード用、ブロック用)はそれぞれ8つまで登録できるようになっている。 大きなファイルシステムになると、そこに全ては 乗り切らなくなりLRUで追い出されることになる。

inodeビットマップ域などのアクセスが遅くなる可能性もあるが、 アクセス頻度が高いため、案外バッファキャッシュから落ちない ような気がする。

逆にファイル削除に伴うiノードの解放は、ext2_free_inode関数によって行われる。単純に解放対象となったiノードに対応するiノードビットマップのビットをクリアするのみである。メモリiノード自体の解放は、呼び出し側(vfs)で行っている。

  ext2_free_inode(メモリiノード)
      iノードビットマップを読み込む(load_inode_bitmap関数)
      ビットマップ上のiノードに対応するビットをクリア
      ブロックグループディスクリプタ読み込み(ext2_get_group_desc関数)
      ブロックグループディスクリプタが管理するフリーiノード数を1増やす
      ◇ブロックグループディスクリプタの属するバッファを遅延書き込み要求(mark_buffer_dirty)
      スーパブロックが管理するフリーiノード数を1増やす
      ◇スーパブロックを遅延書き込み要求(mark_buffer_dirty)
      ◇iノードビットマップを遅延書き込み要求(mark_buffer_dirty)
      if(SYNCマウント？) {
           ◆iノードビットマップをディスクに書き込む(ll_rw_block関数、wait_on_buffer関数)
      }

問題点など

1. SYNCモードのマウントをした場合、 iノードの解放時にiノードビットマップを同期書き込みしているが 実はこの処理は必須ではない。もし同期書き込みをせずマシンが クラッシュしてもこのビットが示すiノードが誰からも参照できなく なるだけであり、ファイルシステム破壊を引き起こすことはない。 性能の面から考えても、ここは非同期書き込みで十分だと思われる。

---

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