Show page source of internal24-113-問題点など #24994

[[PageNavi(internal24-navi)]]

{{{ comment
h2w-title:問題点など
}}}
 

== 問題点など == #SECTION03762000000000000000

  1.  上記ディスクiノード確保アルゴリズムの問題点は、	syncモードのmountであっても新規作成したiノードの	同期書き込みが行われていない点にある。	iノードの書き込み前に、このiノードがディレクトリに	登録された場合、一時的にディスク上のデータ構造に矛盾が生じる。	このタイミングでシステムがクラッシュするとDUPブロックが	発生する可能性がある。
  1.  メモリ上のスーパブロック内にブロックグループのビットマップ	(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 [[BR]]2000年12月09日 (土) 23時55分06秒 JST''1

[[PageNavi(internal24-navi)]]