HDDクラッシュ サルベージ顛末記

2003/05 作成


5月25日深夜に発生したHDDトラブルからの復旧顛末をまとめています。
基本的にこのサイトは「です・ます」調を心がけているのですが、テンパリ具合を醸し出すためにこのコンテンツはわざと「だ・である」調になってます。
ひとまず問題が収束したので、時系列ごとに並び替えました。

ウダウダ書いてますが、結局重要なところは一握りしかありません。
ddで吸い出して、mdconfigで/devに持っていき、fsckしてmountすればある程度吸い出せるということのようです。
BETA2を動かす話も中途半端ですねぇ。RAIDの話も。



5月25日(日) 深夜

ひととおり作業を終え、寝ようと思ってPCの電源を落とす。
すべての作業端末の電源を切り終えるとCPU切り替え機が自動的にサーバの画面に切り替わる。
画面上に見慣れない文字列。
/dev/ad4に異常がある様子。
とりあえず再起動してみるが、後悔。
全く起動しない。
立ち上がっている段階でいくつか重要なデータをサルベージしておくべきだった。

ひととおり原因を考えてみる。
mpdの設定変更をしたのでPCを再起動したことを思い出した。
rebootコマンドを打ったとき、いつものようにACPIがアレなマシンなので、おまじないで電源スイッチをポチッとやるのだが、まちがってリセットボタンを押してたことを思い出す。
それのせいでsyncがとれなかったのか。

とりあえず明日から会社なので後ろ髪をひかれる思いで寝ることに。
サーバの電源を落としたままにする。
その日は1年ぶりにサーバの音が聞こえない静かな夜だったが、復旧方法を考えるとなかなか寝付けない夜だった。

5月26日(月)

セキュリティホールmemoに以前FreeBSDのサルベージに成功した記事が載っていたことを思い出し、会社で調べる。
かなり状況が似ているので期待を持ちつつ会社が終わるのを待つ。
最近忙しいのであっという間に時間が過ぎた。
忙しさをしり目に、定時で引き上げ、秋葉原に直行。職場の視線が熱い。
昼間に会社でAkiba PC Hotline!を見て120GBのHDDがお得であることを確認していたので、そのあたりで探してみる。
結構遅くまでやっているのと、ポイントカードを持っていたこともあり、カクタSofmapで購入。
他にも40GBのHDDを2本と昨日購入したスイッチングハブ用にヒートシンクも購入。
そういえばポイントカードを出さなかったことに、今気がつく。
ばたばたしてたからなぁ。

帰り際、昨日購入したマザボが入る箱をもらい受けに行く。
箱と一緒にタクシーに飛び乗り、自宅についたらさっそく作業開始。

まずはサーバの復旧。メールもばしばし飛んできているはずなので急がなければ。
以前使っていたPentium200のマシンが健在で、HDDも残っていたのでそのままIPアドレスを変更するだけで暫定復旧。
DNS、メール、WWW、SQLなどの最低限のサービスは再開。だいたい21時くらい。実に19時間の停止だったことになる。

とりあえず、最悪の事態は避けられたので、あとはゆっくりサルベージ。
いっそのことマザボも入れ替えることにする。
箱にマザボを収めて組み立てる。
マザボ、ジャンパ多すぎ。もう少しBIOSでカバーして欲しい。
とりあえず組上がり、電源をさしてみる。
電源が入る。スイッチも入れずに・・・
ビデオカードのBIOSは立ち上がるが、次に進まない。
またジャンパとにらめっこか・・・

5月27日(火)代休

今日は土曜日の代休。

暫定版なのでアクセスカウンタをリセット。
壊れた間にどれくらい人が来てたのかも把握したかったので。
直ったらもともとのに足すのかは考え中。SQL文を叩いて手を加えるのは抵抗がある。
トップページにしかけたスクリプトが足すから意味がある。

昼になってもそもそと作業を再開。
付属品を外してジャンパをデフォルトにしたら立ち上がった。
いけてないBIOS画面も変更。
とりあえず、作業用にFreeBSDを新規にインストールすることに。
しかしいきなりけつまずく。FreeBSD5.0のGENERICカーネルではSMPでのi840マザーのACPIをうまく認識してくれない。
Tyanに入れたときも確か同様のことがあったような気がするんだけど、どうやって回避したんだっけなぁ?
他に方法がないのでおそるおそるSMPカーネルが入っている壊れたHDDを入れてみて起動。もちろんシングルユーザモード。
どうやらうまくACPIを通過してくれたようだ。これで安心してこのマシンにインストールができる。
一時的にインストールは他のマシンでやってSMPカーネルを組んでから戻すなど、いくらでも方法はあることだし。

立ち上げたついでに被害状況を調べてみる。
壊れたディスクはPromiseの133カード経由でつながっているためad4で認識される。ad4は4枚のスライスを切ってあり、"/","/usr","/var"とあともう一つは秘密のスライス。
まず、シングルユーザモードで立ち上がっていることから"/"は無事な様子。
/varもマウントできた。SQLのデータも/varに実体があったため無傷の様子。とりあえず日記とBBSは無事なようだ。
秘密のスライスも無事。ということで問題は/usrとなる。
FreeBSDは/homeの実体が/usr/homeなのでこれは危険。
コンフィグファイルのほとんどは/etcなので無事なのだが、mpd関連のコンフィグ/usr/local/etc/mpdと、sambaのコンフィグ/usr/local/samba/conf、あとApache2のコンフィグが/usr/local/apache2/confに入っている。
この3つも危険。
スライスをまたがっての被害がなかった。スライス切っておいてよかった。
最近はスライスを切る意味がないので/とswapしか切らないケースが多いようだが、こうやって助かるケースもあるのでこれからFreeBSDを入れるHDDもきっちりスライスを切ってやろうとつくづく思う。

夕方になってインストール用のPCの準備をする。
暫定で動いているサーバといい、古いPCもこういうことがあるたびに引っぱり出されるので安心して外に出してやることができない。
インストールするのはFreeBSD5.1 BETA2にすることにした。
BETA版は危険だけど、IPFilterが3.4.31になっているのが魅力的。
とりあえずcurrentのMLに申し込んでおこう。
BETAのISOイメージをダウンロード。いつも世話になってるftp4.jp.freebsd.orgがやっぱり速かった。
Seagateの40GBのをRAID1で構築。
Promiseの133とは別にFastrekも持ってたのでこれでミラーを作成。
おそろしく時間がかかる。

1時間くらいたったらDuplicateが終わってた。
BETAも焼き終わってたのでさっそく入れる。
RAID1のディスクはar0で認識されるらしい。
ほかにそれっぽいのが見あたらないし、容量もあっているので、これに決定してインストールする。
man 4 arをひいてみるとなんとなくそれっぽい名前だけど、netgraphがどうのと書かれている。
これであっているのだろうか?
たしか、FreeBSDのuserMLに最近RAIDの話が載っていたのでこっちで調べてみる。
あったこれだ。でもソフトRAIDになってる。ハードウェアRAIDのはずなんだけど。
まぁ、動いているからいいか。

調べものをしているうちに5.1BETA2のインストールが終わっていた。
kerbers5のインストールに失敗した様子。
暗号化規制の問題か、あるいはdisk2を用意しなかったせいだろう。
とりあえず、再起動してさっそくSMPカーネルを作る。
どうせIPFilterやmpd,PostgreSQL関連でまたカーネルを作らなければいけないのでとりあえずSMPだけ有効にしておく。
そうやってGENERICに毛が生えた程度のカーネルができあがる。
はずだったのに、なぜかaic7xxxのモジュールコンパイルに失敗する。
coreを吐いている様子。なぜだろう?
とりあえず、腹が減ったので作業を中断。飯を食う。

晩飯は麻婆豆腐にする。味が薄い。しょうゆを加えるの忘れてた。
いろいろ試してみたけどBETAで続けても埒があかないので5.0releaseをインストール。
やっぱりダメ。cppがコアを吐いている。ひょっとして環境要因か?AMDのK6-2-550なんだけど。

しかたがない。
先にサルベージ計画を進めて、HDDに残っているカーネルを救出して動かしてみよう。
BETA2に入っているIPFilter3.4.31は魅力的なので、なんとか移植する方法も考えよう。/usr/src/sys配下を見繕えばなんとかなるだろう。
場合によっては4.8Rを導入する方向も検討しながら。
とりあえず今日はこの辺でおしまい。

5月28日(水)

といっても、すっかり日付が変わってしまった。
とりあえずの処置が済んでいる余裕だろうか。
だからといって、いつまでもこんなことにつきあっている暇もないので、今日も少しずつ前へ進むとしよう。

カーネルを救出しようと思ったのだが、カーネルの素は/usr/src/sys/i386/confのなかにあったことを思い出す。
消えてる可能性が大きい。
いずれにせよ、復旧させないといかんともしがたいので、救出用に買った120GBのHDDをフォーマットする。
フォーマットが終わったらためしに/mntにマウントしてみた。
続けて壊れた60GBのディスクもつなげてみる。
RAID1で2つつながっていたので、かなりの大所帯になってしまった。
以前、HDDをつなぎすぎて電源が飛んだことを思い出した。あわてて電源の容量を見返すと350W。比較的容量が大きいので大丈夫だろう。

マウント後、さっそく手順どおりddでイメージを吸い出してみる。
固まる。
なぜかわからないがRAIDを組んでいるad6がエラーの断末魔とともに固まってしまう。
なんとなくar0の機嫌が悪いような気がするのでRAIDを解いてFreeBSDを入れ直してみることにしよう。
でも、今日はこれでおしまい。
やっぱりなかなか進まない。

5月29日(木)

今日もぼちぼちはじめるか・・
とりあえず、RAIDの切り離しは昨日済ませておいた。
でも、この40GBのディスクを使うのはやめよう。
やはり自分で立ち上がってもらわなければ。

60GBのディスクは/が無事なのでシングルユーザモードではなんとか起動してくれる。
うっ。うっかりシングルユーザモードでexitしたらマルチユーザモードに入ってしまった。
IPアドレスが有効になる。LAN側のサーバアドレスが競合おこして作業用のWindowsまで止まってしまった。
あわてず急がずarpテーブルをクリアする。Windowsもサーバも。
WinとBSDではarpクリア時のオプションが違うことに気づく。Winは-DでBSDは-d -aのようだ。
これはこれで、収穫あり。i840マザーのオンボードEtherが無事fxpで動いてくれたのが確認できた。
中古で入手したときにEtherをジャンパで無効にされていたのでちょっと不安だった。

さて、気を取り直してもう一度シングルユーザモードで入る。
120GBのディスクもマウントできた。
あとはこっちのもの。
データベースを120GBにそっくりコピー。
tarが使えないのがつらい。tarは/usr/binだったようだ。
とりあえずこれで第一の目的は終了。

続けてddで壊れたディスクのイメージを取りに行く。
これも手順書にあったとおり。
60GBのcountは119150/16/63で120103200なので、こんなコマンドになった。

# dd if=/dev/ad0 /mnt/broken.img bs=512 count=120103200 conv=sync,noerror

こういうときの手順書は本当にありがたい。
うまくサルベージが完了した暁には感謝のメールを送ろう。

さすがに大容量ディスクなだけあって、なかなか処理が終わらない。
風呂の支度をしてもまだ時間があまったので、うちのラボを撮ってみた。
初公開。

内臓を脇腹から露出させたPCっぽいものが2台。場所がないので2段重ね。
下になっているのがi840 DualのPC。上のが作業用のK6-2-550のPC。
暗くて見づらいけど画面左の方で内臓を露出しているのが今回壊れた60GBとバックアップ用の120GBのディスク。
現在バックアップ中。
画面右で2つならんでいるのが40GBの双子。さっきまでRAID1組んでたけどやめさせた。
下にあるのがフルタワー。ちゃんとDDS3のDATドライブがついてるけど、使用者がヘボでバックアップ計画を立てようと思っていてずっと後回しになってたので有効に活用できていない。
そして今に至ると・・

・・・風呂に入ってかれこれ経つが、まだ終わらない。
たまにぽろぽろとエラーを吐いてくれるが、そこで見た感じでは現在14Gくらいまで終わったようだ。
待ってるのがつらいので、そのまま寝てしまおうか。

5月30日(金)

結局そのまま寝てしまった。
朝、会社に出かける10分前までバックアップをやりっぱなしだったことを忘れていた。
出かける前のばたばたした中、コンソールを確認し、プロンプトが帰ってきているところを見て安心する。
電気代がもったいないのでもちろん電源を切って会社に出かける。

飲み会があったので帰ってくるのが遅くなった。
結局今日も曜日が変わってからの作業だ。
まずは作業用PCを立ち上げる。
昨日は使うのをやめたけど、安心してファイルを救出するためにはこっちを使った方が安心。
それに/usrが使えないのはつらすぎる。

その前に落とし穴。
インストール時はar0で入れたけど、分割したのでad4になってしまった。
rootがうまくマウントできない。
それもそのはず、fstabの値がおかしいのである。
これはやったことがあるので簡単。
rootがマウントできないと言われるのでまずは「ufs:ad4s1a」でrootをroでマウントする。
この時点で強制的にシングルユーザモードなのであとはrootを再マウントし、/usrもマウントし、エディタでfstabを編集すればよい。

# mount /
# mount /dev/ad4s1d /usr
# vi /etc/fstab

/varがないので怒られるが、編集は問題ないので続ける。
編集が終わったら保存してexitしてみる。するとマルチユーザモードになる。
うまくfstabを読み込めたのでちゃんと起動した。
とりあえず一旦電源を落として、例の120GBを接続して再起動。
ここでようやくネットワークがつながった状態で120GBに入ったデータを吸い出せるようになる。
とりあえず、別途救出したSQLのデータを暫定で動いているサーバに転送した。
もちろんtarで固めるのを忘れない。そのために作業用のPCでやっているわけだし。

ここからは暫定サーバでの作業。
さっそくtarを展開する。
展開したものを指定して、postmasterを再起動してみる。またしてもはまる。
どうやら古いサーバから新しいサーバにしたときに、PostgreSQLのバージョンを上げていたらしく、新しいバージョンのデータを古いバージョンで読み込ませようとしたため、fatalが発生した。
暫定PCのSQLを新しいバージョンにするよりも新しいPCのセットアップをした方がいい気がしてきた。
まぁ、でもこれはこれでバックグラウンドで進められるのでSQLのバージョンも並行して進めることにしよう。
自分で書いたコンテンツが手順書となる。やっぱり書いておいてよかった。

こうして日記とBBSとアクセスカウンタが戻った。
障害発生から6日目。これがふつうのSI会社だったらとっくにつぶれていたことだろう。
まぁ、のんびりやってたしなぁ。
日記の試し書きしてみたかったけど、日付が変わってしまったのでとりあえずやめておく。
そもそもこの日付が変わるのをなんとかしたいが、それより先に復旧させないと。

SQLの救出には成功したが、これで終わりではない。
肝心の/usrの中身がさっぱり救出されていないのだ。
もちろんこれからやるわけだが。

5月31日(土)

タスクがいろいろあるのでちょっとリストアップしてみよう。

番号 タスク 小タスク 優先順位 完了日
1-1 仮復旧 DNS S 5/26
1-2 メール S 5/26
1-3 WWW A 5/26
2-1 データの復旧 60GB HDDの吸い出し B 5/29
2-2 データベースの復旧 A 5/30
3-1 再構築 FreeBSDをインストール A
3-2 カーネルをSMP対応 B
3-3 バックアップデータの戻し B
3-4 i840マザーへの移植 B
4-1 本復旧 BINDのインストール C
4-2 Apacheのインストール C
4-3 PostgreSQLのインストール C
4-4 カーネル再構築 C
4-5 PPPoEの設定 C
4-6 IPFilter/ipnatの設定 C

まだ半分もタスク終わってなかったのか・・

さて、今日も作業を再開する。
FreeBSDのインストールは半分おわっているのだが、カーネルの再構築で手間取っているのでなかなか完了しない。
27日のコアを吐く現象。環境依存の可能性を検証するため、ついにもう一台引っぱり出してきた。
復旧に携わったPCはこれで5台。持っている方も持っている方だが・・
さっそくカーネルをコンパイルしてみる。make depend ・・・通った。やっぱりTualatinのCel1.4Gだけあって速い。
これまで引っかかっていたのがmake dependだったのでやっぱり環境依存だったようだ。
K6だとダメになるのはどうかと思うが・・
ちなみにこれが5台目。よく見るとHDDが3段重ね。


make dependが成功したのでここまできたら一気にインストールしたくなる。続いてmake ・・・止まる。
errorを吐いて止まった。どうもCPUのスケジューラまわりのコンパイルに失敗したようだ。
いつになったらまともに動くのやら。

ちょっと整理しておこう。現在5つのPCと4つのHDDで作業をしている。
4つのHDDはそれぞれ
40GB => FreeBSD 5.0R(復旧用)
40GB => FreeBSD 5.1BETA2(復旧用2)
60GB => FreeBSD 5.0R(壊れ)
120GB => 救済用

どんな手順で作ったかはすっかり忘れてしまったが、60GBには5.0Rで作ったSMPカーネルがまだ残っている。
でも5.1BETA2で今回は行きたい。
おそらく5.0Rを入れた40GBにSMPカーネルを移植すればすんなり行くだろう。
でも、ここはうちのサイト名に恥じないようにやはり実験を敢行しなくては。
ということで、5.1BETA2が入っている40GBに5.0RのSMPカーネルを移植してみた。
結論、動いた。
張り切って5.1BETA2でのSMPカーネルをコンパイル。
make dependは通ったが、やっぱりmakeでCPUのスケジューラがエラーを吐く。
FreeBSD currentのMLを見て探してみる。
ACPIってのがいっぱいならんでいる。
英語読むのはつらいよ。

英語読むの面倒なのでエラー解析することにした。
メッセージを解析するためにscriptを使う。定番だが効果的。

# script makelog
# make

エラーが出るまでだいぶ時間がかかる。
よくみたらscriptを使うまでもなくmachdep.oが原因であることが判明。
machdep.oはmachdep.cからできるので、これが原因だろう。

machdep.o: In function `cpu_idle':
machdep.o(.text+0x14a7): undefined reference to `sched_runnable'
*** Error code 1

Stop in /usr/src/sys/i386/compile/SMP.

machdep.cを探す。/usr/src/sys/i386/i386にあった。
更新日をみると最近更新したようだ。

-rw-r--r-- 1 root wheel 77945 May 13 20:35 machdep.c

ひょっとしたらcurrentに最新版があるかもしれない。
さっそくftpでのぞきに行ってみる。
しまった。カーネルがIPFilter対応のものなのでルールが設定していないのでftpが使えない。
あわてず急がずこれも手順書から入力。
ルールの方は適当なのでpass in all pass out allでいいだろう。
そして取りに行く。場所はいつものftp4.jp.freebsd.org

-rw-r--r-- 1 ftpmirror ftpmirror 77945 May 14 08:42 machdep.c

ビンゴ。
さっそくファイルを差し替えて再構築。
やっぱり失敗。同じところで。
おかしい。diffを取ってみよう。

# diff machdep.c machdep.c.old
#

・・・ふりだしに戻る。

ちょっとくじけそうになった。
気分転換に別のことをやってみる。
壊れたディスクのイメージを吸い出したので、イメージを今度は張り付けてみることにする。
手順書では吸い出したイメージをvnconfigでデバイスを割り当ててからやることになっている。
でもFreeBSD5.0Rからはvnconfigがなくなってmdconfigに引き継がれたというメッセージが帰ってきた。
移転先まで教えてくれるとはありがたい。
さっそくman mdconfigで使い方を教えてもらう。
こんな感じで使うらしい。

# mdconfig -a -t vnode -f /mnt/broken.img -u 4
# mount -f -o ro /dev/md4s1a /opt

1行目はbroken.imgを/dev/md4に割り当てるという意味。
2行目は/dev/md4s1aを/optに割り当てるという意味。
端的にいうと、/mntにマウントしたHDDに入っているimgファイルを/optにマウントするという感じ。
ん?なんかに似ている。
最近Windowsで流行っているCDやDVDのイメージをマウントするdaemon toolとかいうのに似ているのか。
ちなみにUNIX(もどきも含む)の世界でdaemon toolと言ったらqmailのツールなのだが・
とにかくイメージが作成できたのであとはfsckしまくろう。

# fsck /dev/md4s1d
# fsck /dev/md4s1e
# fsck /dev/md4s1f

途中なんか言われたけど全部yesで答えた。
話の流れから、なんとなくSALVAGEという言葉がみえたので、どうやらデータを勝手にサルベージしてくれているらしい。
ありがたい。
そして壊れたはずの/usrをマウントしてみる。

# umount /opt
# mount /dev/md4s1e /opt

その前に/optをumountしておかなければ。
そして、どうなったかというと・・

無傷だ。
ほとんど無傷と言ってもよいだろう。
不思議なこともあるものだ。
というか、fsck凄すぎ。ddも。

こうなってみたら試してみたくなってきた。
FreeBSD5.0Rをいれた40GBにそっくりそのままもどしてみよう。
いよいよ実験らしくなってきた。
と思ったけど、今日はもうおしまい。気がついたら4時をすぎているし。
これは明日の楽しみに取っておくことにしよう。

6月1日(日)

今日から6月か。
とりあえず、SMPカーネルを適用してしまったのでi840マザーでしか作業できなくなってしまったので、復旧用に用意した5台のうち2台が用を終えた。
それにこれからi840マシンに手を加えていく上で、これら2台は物理的にじゃまになる。
フタをしてどこかに隠しておこう。

昨日やり残した5.0Rへの丸ごとコピーをするべく作業を再開。

・・・どうにもややこしい。
作業はシングルユーザモードがいいだろう。
コピーコマンドに注意。
とりあえずman cpで確認。
ふむふむ。Rとfとpが使える。

# cd /mnt/60
# cp -Rfp ./ /

プロンプトがしばらく無応答になる。
心配なのでもう一度manを読むとvオプションで冗長モード発動らしい。
tarでつかうやつだな。
とりあえずCtrl+Cで中断して。

^C
# cp -Rfpv ./ /

おー、出てくる出てくる。
cpコマンドも奥が深い。やはり困ったときはmanを読めということか。

今思えば、エラーを拾うために2>出しておけばよかったと後悔。

約30分ほどでコピーは終了。
再起動してみる。
スライスを変えたのでめちゃくちゃになってる。
とりあえずシングルユーザモードで作業する羽目に。
仮で/usrをマウントしてviを使おうとしたら、viがないと言われる。
よく見たら/varと入れ替わっていた。前回のときは/usrがad4s1eだったが、今回はsd4s1dになってる。
しかたがないので/varもマウントし、/var/bin/viなどど小手先でごまかしてみた。
やっぱりだめ。viがshared linkを使っていたらしく、/usr/libexecを参照していた。
やはり横着はいかんということか。/usrと/varをumountして、ad4s1dを/usrにマウントし直してfstabを修正した。
今度はちゃんと起動してくれた。

ログインしてみる。
rootはok。今度はユーザでログインしてみる。
プロンプトが変。しかもhomeがない。
思い出した。今回はクラッシュ時に耐え得るように/usr/homeも別スライスを切ったんだった。
手動でマウントしたあとfstabに追加して、事なきを得た。
あとは組み上げてしまえばよい。

ちなみに、BETA2からこっそり抜いておいたIPFilter3.4.31を入れて5.0Rでコンパイルしてみた。
案の定止まった・・

実はすでに元に戻せる状態にはあるのだが、120GBのディスクを有効活用するために最後の仕事、データ移行が残っている。
Samba用のボリュームに実はもう一台60GBがあったのだが、こいつを120GBに移さなければならない。
作業は単純だが、時間がかかる。

時間がかかったがデータ移行も完了。
あとは緊急メンテをするばかり。

メンテナンス終了。
無事に復活した。
新しいサーバは前よりも静かだ。
変えてよかった。
ついでにスイッチングハブも交換した。
はじめは動きが悪く気に入らなかったが、ポート設定をちゃんとやったらよくなった。

これにて、サルベージ顛末記はひとまず終了。
あとは後始末が残っている。
壊れたHDDを元通り60GBのディスクとして使えるのか。
バックアップスケジュールはどう立てるのか。

昨日作ったタスクリストからは大きく違ってしまったが、結果オーライということで。

6月2日(月)

cronがsetuidのdiffを報告してきた。
ファイルをそっくり入れ替えただけあってかなり長文・・
lost+foundの中をチェックし忘れてたので確認した。
/varの中にファイルが3つのみ。
/var/runのpidファイルと思われるものが2つ。空っぽのファイルが1つ。おそらく空っぽのものはなにかのロックファイルだろう。
実害はやっぱりゼロだったようだ。

/varが無事なので障害発生時のmessagesが残っていた。
確認してみる。

May 25 20:41:25 loki root: /dev/ad4s1e: 180310 files, 951715 used, 11141347 free(87651 frags, 1381712 blocks, 0.7% fragmentation)
May 25 20:42:00 loki root: /dev/ad4s1f: 888 files, 4828915 used, 5572401 free (161 frags, 696530 blocks, 0.0% fragmentation)
May 25 20:42:07 loki kernel: ad4: hard error cmd=read fsbn 236917694 of 118458847-118458878
May 25 20:42:09 loki kernel: trying PIO mode
May 25 20:42:09 loki kernel: ad4: hard error cmd=read fsbn 236917694 of 118458847-118458878
May 25 20:42:10 loki kernel: status=59 error=40
May 25 20:42:14 loki kernel: ad4: hard error cmd=read fsbn 221870014 of 110935007-110935038
May 25 20:42:28 loki kernel: status=59 error=40
May 25 20:42:29 loki kernel: ad4: hard error cmd=read fsbn 212978814 of 106489407-106489438
May 25 20:42:29 loki kernel: status=59 error=40
May 25 20:42:29 loki kernel: ad4: hard error cmd=read fsbn 155660414 of 77830207-77830238
May 25 20:42:29 loki kernel: status=59 error=40
May 25 20:42:29 loki kernel: ad4: hard error cmd=read fsbn 239174718 of 119587359-119587390
May 25 20:42:29 loki kernel: status=59 error=40
May 25 20:42:29 loki kernel: handle_workitem_freeblocks: block count
May 25 20:42:29 loki kernel: ad4: hard error cmd=read fsbn 20910398 of 10455199-10455230
May 25 20:42:29 loki kernel: status=59 error=40
May 25 20:42:29 loki root: /dev/ad4s1d: CANNOT CREATE SNAPSHOT /var/.fsck_snapshot: Input/output error
May 25 20:42:29 loki root:
May 25 20:42:29 loki root: /dev/ad4s1d: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.

やっぱり電源と間違ってリセットボタンを押したのが原因のようだ。
再起動時にバックグラウンドでfsckが走って、その後にread errorを出している。
20時にディスクエラーが起きたのに、日付が変わった2時までちゃんと動いていたことになる。
放っておいたらいつまで動いていたのだろうか?

今回はマザーを変えたのでACPIまわりの挙動が安定した。
おまじないで電源をポチッとやる必要もなくなったので、同様の問題もなくなるだろう。


参考文献

セキュリティホールmemo http://www.st.ryukoku.ac.jp/~kjm/security/memo/
復活の日: FreeBSD ディスククラッシュ事件総括 http://fromto.cc/hosokawa/diary/2002/20021107-home1/index.html
FreeBSD 日本語マニュアル検索 http://www.jp.freebsd.org/man-jp/search.html
FreeBSD-users-jp メーリングリストアーカイブ http://home.jp.freebsd.org/mail-list/FreeBSD-users-jp/


もどる