[[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)]]