We've got company

メール受信がタイムアウトしたので、何かトラブルかと思ってサーバにsshしたら、プロンプトが出るまで数分かかった。 何か刺さってるのかとtopを見たが特にCPU食ってるタスクもない。メモリ使用量の多いタスクを止めようとして、いつもの調子で/usr/l→TABとかやったら固まる（１分後くらいに反応）。な、何が起きている！？ ひとまず落ち着いてtail /var/log/messages…また固まった。今度は何分待っても出てこない。C-c連打でやっとプロンプトに返ってきた。 再起動…が一瞬頭をよぎるが、もし再起動に失敗したらNOCの主が帰ってくるまでどうしようもなくなる。 祈るようにdmesg。今度は反応があった。そこには ad4: FAILURE - READ_DMA status=51<READY,DSC,ERROR> 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はゼロなので、今日明日壊れるということもない様子。まぁ、不安だから早めに交換しよう…