2020/12/10の朝、Radiko関係ページへのアクセス状況を見ようとサーバーへアクセスしたのですが、なぜかエラーに。
ニュースサイトなどは問題無くアクセス出来ます。すごく嫌な予感。
普段はモニターの画面を表示させていないのですが、モニターを切り替えて直接コンソールを覗き込んでみると、、、、が〜ん、OSの起動画面途中でデータディスクが見つからないというエラーを出して、FreeBSD OSが起動途中に停止していました。
実は、以前からHDDがエラーを吐き出していることに気が付いていました。
(ada1:ahcich3:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 40 00 d9 9b 40 24 00 00 00 00 00 (ada1:ahcich3:0:0:0): CAM status: Uncorrectable parity/CRC error (ada1:ahcich3:0:0:0): Retrying command (ada1:ahcich3:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 40 c0 69 af 40 24 00 00 00 00 00 (ada1:ahcich3:0:0:0): CAM status: Uncorrectable parity/CRC error (ada1:ahcich3:0:0:0): Retrying command (ada1:ahcich3:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 40 40 8b d6 40 24 00 00 00 00 00 (ada1:ahcich3:0:0:0): CAM status: Uncorrectable parity/CRC error (ada1:ahcich3:0:0:0): Retrying command (ada1:ahcich3:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 40 00 ce 24 40 25 00 00 00 00 00 (ada1:ahcich3:0:0:0): CAM status: Uncorrectable parity/CRC error (ada1:ahcich3:0:0:0): Retrying command (ada1:ahcich3:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 40 40 ce 24 40 25 00 00 00 00 00 (ada1:ahcich3:0:0:0): CAM status: Uncorrectable parity/CRC error (ada1:ahcich3:0:0:0): Retrying command (ada1:ahcich3:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 40 40 cf 24 40 25 00 00 00 00 00 (ada1:ahcich3:0:0:0): CAM status: Uncorrectable parity/CRC error (ada1:ahcich3:0:0:0): Retrying command (ada1:ahcich3:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 40 80 cf 24 40 25 00 00 00 00 00 (ada1:ahcich3:0:0:0): CAM status: Uncorrectable parity/CRC error (ada1:ahcich3:0:0:0): Retrying command
幸いなことにエラーメッセージは出力されますが、サーバーの動作には特に影響が出ていなかったため、そろそろHDD交換時期かなと思っていたものの先延ばしにしてきました。
最近エラーの出力行数が増加、頻度も増加してきたので週末にHDD交換しようかと思っていたところ、radiko.jp の仕様変更でいきなりホームページへのアクセス数が激増。Webサーバーを止められなくなってしまいました。
そして、12/10朝を迎え、いきなり止まってしまいました。
幸いなことに電源オフ→オンでサーバーは復活しましたが、エラーは出続けています。
平日でしたが、HDDを交換することにしました。今回は、OS側のHDDには触らず、/home下、データディスクだけなので、rsync を使用して新しいデータHDDを作り、その後交換することにしました。
手順:
- 代わりのHDDをUSB HDDケースに入れてUSBケーブルでサーバーと接続する。da0 として認識される。
- bsdconfig で HDDをパーティション切りする。この時、既存の ada1 と同じ構成にしておくと楽。
- USB HDDを /mnt にマウント
- ローカルバックアップなので、
rsync -av /src/foo /dest
形式を使用。
# cd /home
# rsync -av . /mnt - データディスクは常に更新されているので、httpd, mysql を停止した後、もう一度
#rsync -av . /mnt
を発行して、前回のコマンド発行後から書き換わったファイルを再度同期。 - 更新ファイルが無くなったところでPCをシャットダウン。
- SATAデータディスクとUSB HDDの中身を交換。(どちらもSATAなので)
- この後でサーバーを起動。
これで作業は完了となるはずだったのですが、、、、、、
エラーが止まらない。
まさか、HDDじゃなくてPC側?
- SATAケーブルを交換してみたもののエラー出力は止まらず。
- 更にSATAポートを交換して、エラー頻度は低下したものの、エラー自体は止まらず。
もしかしてマザーボード上のチップの故障?
さらに、HDDを接続するSATA ポートを変更。これでしばらく様子見の予定だったんですが、ポート交換後二日経過した12/16、状況悪化。
HDDエラーが止まらないばかりか、PanicでOSがリブートしてしまう。その時に動いていたログ解析データが死ぬ、Radikoの録音に失敗するなどなど。これは週末まで待てない。
直ぐにHDD交換出来てNICが2枚入っている予備機を探したところ、Asrock AD510PV がありましたので、このPCのHDDを外して、サーバーからHDDを移設。マザーボードじゃなくHDDが本当に壊れている可能性も捨てきれないので、OS起動した後Kernelメッセージを観察していましたが、上記のエラーは出てこず。Dell Vostro220s マザーボードが原因と、確定しました。
Core2duo E8400(3GHz x2) + 4GB から Atom D510(1.6GHz x4)+4GB への交換です。これはスペックダウンなのか同等なのか?
一時的な回避と考えていますが、これで問題なく運用できるなら、次の本番機はVostro220sの筐体を再利用してゆっくり準備しようかな。
追記
Atom D510ベースのボードではHDDのエラーは出ないものの、ローカルで使うにはレスポンスにちょっと不満が出ます。ドキュメントを表示する分には問題無いものの、書く場合のレスポンスが外部からのアクセス数の影響を受けてしまい、編集効率が低下することがあります。Vostro220sに戻したい。
Vostro220s の内蔵SATAボードは諦め、PCIeスロットに拡張SATAボードを入れて、それにSATA HDDを接続し直して、Core2Duoベースのマザーボードでの運用に戻しました。SATAチップが故障しつつあるなら、これで解決するはず。
確かに、エラーの頻度は低下したものの、エラー自体は以下のように出続けています。
Feb 5 14:44:31 tokyo kernel: (ada1:ahcich2:0:0:0): WRITE_DMA. ACB: ca 00 28 51 b0 40 00 00 00 00 40 00 Feb 5 14:44:31 tokyo kernel: (ada1:ahcich2:0:0:0): CAM status: Uncorrectable parity/CRC error Feb 5 14:44:31 tokyo kernel: (ada1:ahcich2:0:0:0): Retrying command
やむを得ず、しばらくVostro220sを運用から外し、別のCore2DuoベースのPCと置き換えて運用することにしました。
Core2Duo E7200 + 4GBメモリのマザーボードに、HDDを丸ごと引っ越しました。当然、このPCではHDDエラーは出ません。しばらくこのPCで運用して、その間にVostro220sを復旧したいと思います。