「HDDが壊れたかもしれない」と書いているのは100%確信がないからで、今までHDDが壊れた時はセクターへのリード・ライトが失敗して、エラーが表示されるというわかりやすい問題が発生したか、そもそもドライブがスピンしなくなって、全く使えなくなった場合しか経験していないかった。1月4日にFreeBSDの日次セキュリティチェックが不審な状況を検出したことがそもそもの発端と言える。パッケージでインストールしたソフトのチェックサムがおかしくなったようで、大量にエラーが検出された。何も変更していないので、なぜそんなことが起きたのだろうと思ったが、それほど深刻には考えなかった。その後、定時に実行しているジョブの終了結果のメールが送られていないので、実行に失敗したのかと思ってNAS kitにログインして調べてみると、ジョブは実行されているのがファイルの生成状況からわかった。という事はメールが送れなかったという事だが、この時点でもまだ状況がわからず、色々調べていると、ジョブの結果から重要な部分をフィルタリングして、メールを送るperlスクリプトがコンパイルエラーで実行できないのが分かった。理由はモジュールが発見できないからだ。
ここで、ようやくパッケージのチェックサムの問題がこのperlスクリプトの問題とリンクしているの気づいた。どうやらファイルシステムが壊れているようなのだ。FreeBSDの日次セキュリティチェックのメールをもう一度よく見ると、"Checking negative group permissions"でもエラーが検出されていて、そこで検出されたエラーがperlスクリプトで使うモジュールであり、そのモジュールはチェックサムの照合でもエラーが発生している。
"Checking negative group permissions"のエラーは実は昨年の12月18日にも発生していて、その時は何が起きているか調べているうちに、NAS kitがリブートしてしまい、ファイルシステムがおかしくなって立ち上がらくなってしまった。今回も同様にリブートして、立ち上がらなくなってしまった。
HDDはsmartmontoolsでチェックするようにしていて、週1回のショートセルフテストと、月1回のロングセルフテストを実行して、エラーは検出されていない。12月18日にファイルシステムが壊れた後にもチェックしたが、エラーは検出されなかったので、そのままHDDをフォーマットして使いまわしていたのだが、2週間程度で再度おかしくなったという事は、きっと壊れたのだろう。HDDのattributeを読みだしてみると、UDMAのエラーが2回検出されているのだが、この値が問題発生以前には0だったかどうかがわからない。
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 2
今度は新しいHDDを買ってきてFreeBSDをインストールしたが、これでもエラーが発生したら、NAS kitがおかしいという事になるだろう。新年早々厄介なことだが、暫く様子を見るしかない。