メール受信がタイムアウトしたので、何かトラブルかと思ってサーバにsshしたら、プロンプトが出るまで数分かかった。
何か刺さってるのかとtopを見たが特にCPU食ってるタスクもない。メモリ使用量の多いタスクを止めようとして、いつもの調子で/usr/l→TABとかやったら固まる(1分後くらいに反応)。な、何が起きている!?
ひとまず落ち着いてtail /var/log/messages…また固まった。今度は何分待っても出てこない。C-c連打でやっとプロンプトに返ってきた。
再起動…が一瞬頭をよぎるが、もし再起動に失敗したらNOCの主が帰ってくるまでどうしようもなくなる。
祈るようにdmesg。今度は反応があった。そこには
ad4: FAILURE – READ_DMA status=51 error=40 LBA=8
g_vfs_done():ad4s1e[READ(offset=23891902464, length=16384)]error = 5
がびっしりと…うわああああ。
ついにディスクが逝ったか…と思ったけどよく見るとoffsetの値は全部同じ。どうやら全面的に壊れたわけではなさそうだ。要するに破損したセクタを読み込もうとして固まっている様子。
offset=23891902464, length=16384はそれぞれ単位がbytesなので、512で割って46663872番目から32セクタがいかれてると思われる。
とりあえずddで破損セクタをサーチ。
# dd if=/dev/ad4s1e of=/dev/null skip=46663872 count=32 conv=noerror
案の定先ほどのエラーがコンソールに出るが、他に破損セクタはなく終了。んじゃbadsectするか…と思ったが、この時点で反応が正常に復帰。先ほどのddをもう一度実行すると、今度はノーエラーで終了した。どうやらhdd自身のセクタ代替機能が働いて回避するようになったらしい。
念のためsmartmontoolsをインストールして、
# smartctl -A /dev/ad4
を実行してみると、Reallocated_Sector_Ctが173。173セクタほど破損しているようだ。幸い、断末魔の叫びであるSpin_Retry_Countはゼロなので、今日明日壊れるということもない様子。まぁ、不安だから早めに交換しよう…

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

次のHTML タグと属性が使えます: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>