ここ数日のポストでzfsが怪しいとかsi3124が怪しいとか書いていたが、どうにもおかしいので、memtest86を用いてメモリの動作チェックを行ってみた。その結果、「確実に」memtest86ごとリセットがかかってしまうことが判明、zfsもsi3124もおかしいわけではなかった。

詳細は今後追跡してポストするが、まずは誤報だったことを訂正させていただきたく思う。

しかしひどい話だなぁ。

追記：メモリ２本のうち、１本を抜いて動かしてみたところmemtest86を支障なくクリアする。これが原因、でビンゴのようだ。大変失礼しました。

追記：メモリに障害があったせいで不穏な動作をしていたのは確かではあるのだが、それによってraidz2で構成したプールが完全に壊れてしまった(データ中に多量の破損ビットがある状態になってしまった)ことは、落ち着いてよく考えるとものすごい怖い話ではないだろうか。メモリが壊れていても、scrubを掛ける前までの動作中には問題を検出できないことも考えると、zfsはECC付きメモリがない環境では使用してはいけない、、のではないかと思うのだがどうだろうか。安定して動作しているように見えたメモリが、気温や振動や電源装置のコンデンサの経年劣化による電圧変動などで正常に動作しなくなるというのはよくある話なのだが。。

追記：原因はメモリの可能性が高まった。下記のポストは全然的外れである可能性が高いのでいったん打ち消し線で削除させていただくことにした。追って調査の上報告したい。

追記し続けるのも微妙なので新しいポストに。

前回のポストで大容量転送は大丈夫っぽい、と書いたところだが、さらに確認を行うために200GBばかりファイルを延々とコピーしてみた。あまりにも時間がかかるので放置していたのだが、朝になって見てみるとつないでいたPuTTYは全部切れてるしファイル転送は失敗している。zpool statusはすべてONLINEになっているのだが、怪しいのでscrubしてみると全部の玉でChecksum Error。転送できた量が120GBそこそこに対して、8つの玉でそれぞれ2k～3kくらいのChecksum Errorが報告されていて、完全にunrecoverable状態。messagesやらdmesgやらuptimeで見る限り、不自然なエラーは報告されていなくて再起動した様子もない。

そして一度zpool clearしてからscrubしなおしていたらpanic、マシンごと再起動がかかった。

どれくらい問題の再現性があるかはわからないが、これまでのバックアップを集約することを考えるとこの数倍程度の容量は一回で転送することが多々ありそうで、これをスルーするわけにはいかなそう。よもやハードウェアの信頼性よりもドライバの信頼性が低くてどうしようもなくなるとは思わなかった。

ひとまず、このままでは使い物にならないことだけは明白だ。どうしたものか。

追記：原因はメモリの可能性が高まった。下記のポストは全然的外れである可能性が高いのでいったん打ち消し線で削除させていただくことにした。追って調査の上報告したい。

メモリがきちんと動くことを検証したのち、再度下記のテストを行った。やはりディスクの電源を突然抜くと、panicまで起こさないものの処理を受け付けない状態になってしまった。sil3124を用いたHBAではホットプラグはやめておいた方が良い、ということだろう。

新しくわかったことだが、GA-G31M-ES2Lに乗っているrealtekのGbEアダプタも他の例に漏れず高負荷時におかしくなる。たちが悪いのは、ifconfigで一度downさせて再度upしても疎通が戻らない。OSにはエラーとして検知されない。rgeドライバが悪いかどうかはさておき、評判もよろしくないことだしPro/1000かBroadcomかのどちらかのインタフェイスを入れたいところ。

zfsを使って構築したNASにトーチャーテストをしているのだが、なかなか難しい。これまでに試したのは、下記のような感じ。ちなみに環境は前回のハードウェアにopensolaris2008.11(snv_101b)な環境。

■動作中のディスクの電源ケーブルを突然抜く。一度本体の電源を落としてから再接続して再認識させる。
これは問題なし。ディスクの電源が抜かれた後の最初のプールへのアクセスでエラーは検知され、自動的にREMOVE状態になった。電源を落として電源ケーブルをつなぎ直して起動すると、勝手にONLINE状態に戻る。(この動作が本当に正しいのかは若干疑問ではある)

■動作中のディスクの電源ケーブルを突然抜く。本体の電源を落とさずに再接続して認識させる。
これがダメ。一度切断されたHDDは再度接続しても/dev/dskには現れないので、cfgadmでconfigureしてやるのがスジのようなのだが、configureしなおしてすぐ、OSごと転けてしまう。こちら(ZFS ストレージプール内のデバイスを置き換える)を見ると、本当はofflineにしてやらないといけないのかもしれないが、アレイ中の玉をofflineに出来ないのでうまくいかず。もしかすると置き換えることができないデバイス扱い、ということなのだろうか。可能であればホットスワップしたいところ、追って調査中。もしかしてSil3124のドライバがタコだったら嫌(*)だなと思っているところ。どうしようもなくなってしまったら、あちこちである程度実績があるっぽいAOC-SAT2-MV8を使うことも検討しようと思う。

(*)
・[zfs-discuss] SIL3124 stability?なんてのがMLに流れているしー。
・さらにZFS Fileserver: Lost in Hardwareの中で "there’s a bug in the Sil3124 driver that loses an interrupt under heavy load"とか言われてるのもひじょーに嫌。定期的にscrubすればなんとかなる、、かもしれないとはいえ、業務じゃ無理だな。
・man si3124すると、NCQとMultiplierは未対応だよ、とある。じゃぁhotplugはどうかというと、ダメとは明記されていないんだが。
・Thread: SATA controller suggestionではsil3124でhotplugうまくいかねー、という人のポストが華麗にスルーされている。
・それどころかmarvelのチップでもトラブルがあるらしい。とほほ…
・Thread: SATA cards, any recommendations?あたりでは、単にunplugしただけでフリーズしたという話もある。しかし結局ここでもhotplug対応のオススメカードの結論はないなぁ。

■障害の起きた玉をホットスペアに切り替える
全く同じ玉をオンボードSATAインタフェイスにつないで、そちらにreplaceしようとしたところ、device is too smallと言われてしまってreplaceできない。同じ玉なのにtoo smallとはこれいかに。それはそれとしても、世のHDDは微妙に容量に差がある。ディスク丸ごとではなく、容量指定で切ったスライス単位でプールを構成しないと後が怖いんではないか、と思う。これも調査中。。

■そこそこ高負荷っぽいテスト
高負荷テストだけでは今のところ落ちていない。圧縮をgzip-9にするとさすがに時々コンソールまで黙る(これはこれでどうかと思うが、カーネルレベルで高負荷をかけてるんだからある意味仕方がないかもしれない)が、基本的に圧縮するつもりはないので問題なし。

失敗したのはオンボードのSATAインタフェイスはcmdk扱いになってしまうのでホットスワップできなさそうなところ。これはこれで困るので別口でインタフェイスを追加しなければならない。

ひとまずしばらくの方針としては、上の(*)にメモした情報と現状を元に、1)壊れたら電源を切ってハードウェアを入れ替える。2)ホットスペアはとりあえず無し。壊れたらすぐ人力で玉を変えるホットスペアは１台つけておく。replace出来ない問題は追跡する。3)hotswap/hotplugはしない、という方向でいけば、とりあえず最悪のデータロスは防げそうな気配。高負荷時に割り込みを取りこぼすという件は再現していないので再現してから考える。

なかなか思ったようにはいかないものだが、さんざん作って壊してを繰り返した結果、システムに慣れてきたように思う。経験値稼ぎだと思えばこれも無駄ではないだろう。

時間があるのは連休中だけ。なんとか連休のうちに立ち上げてしまいたいところ。引き続き調査。