2006年04月04日
止まらない仕組みを目指して（２）
壊れて困るファイルってなんだろう・・・
どんなファイルも壊れれば多少は困りますが、設定ファイルやデータファイルなどに関しては、最悪壊れてしまってもシステム側の処理でどうにでも対処できそうです。エラーを検出した時点で関連するデーモンを止めてしまえばよいのですから。
本気で困るのは、エラーを検出したときに身動きがとれなくなる状態(シェルが起動できないとか)です。
そこで、/{lib,sbin,bin} をramdiskにいれてみてはどうだろうと思い立ちました。
起動時にtmpfsで/{lib,sbin,bin}をmountし、ディスクから内容をコピー・・・・・
これならHDDが壊れても平気、メモリが壊れたらそもそもカーネルも無事ではないでしょう。
最も懸念している「中途半端に生きている状態」を回避することはできそうです。
早速起動スクリプト(俗に言うrcスクリプト)に mount -t tmpfs と書きかけて・・・
そういえば init もglibcに依存してることに気づきました(笑
init 起動前にtmpfsのmountとファイルのコピーまで完了していなければいけませんね。
ということは、initrd のお世話にならないといけなさそうです。
どんなファイルも壊れれば多少は困りますが、設定ファイルやデータファイルなどに関しては、最悪壊れてしまってもシステム側の処理でどうにでも対処できそうです。エラーを検出した時点で関連するデーモンを止めてしまえばよいのですから。
本気で困るのは、エラーを検出したときに身動きがとれなくなる状態(シェルが起動できないとか)です。
そこで、/{lib,sbin,bin} をramdiskにいれてみてはどうだろうと思い立ちました。
起動時にtmpfsで/{lib,sbin,bin}をmountし、ディスクから内容をコピー・・・・・
これならHDDが壊れても平気、メモリが壊れたらそもそもカーネルも無事ではないでしょう。
最も懸念している「中途半端に生きている状態」を回避することはできそうです。
早速起動スクリプト(俗に言うrcスクリプト)に mount -t tmpfs と書きかけて・・・
そういえば init もglibcに依存してることに気づきました(笑
init 起動前にtmpfsのmountとファイルのコピーまで完了していなければいけませんね。
ということは、initrd のお世話にならないといけなさそうです。
klab_gijutsu2 at 16:01│Comments(0)│TrackBack(0)
