[メールアドレス保護]


On Sun, 08 Jun 2008 23:34:27 +0900
Hirohito 
<[&#x30E1;&#x30FC;&#x30EB;&#x30A2;&#x30C9;&#x30EC;&#x30B9;&#x4FDD;&#x8B77;]> 
wrote:

> あるいは、上記でメインボード入れ替えと書いていますが、
> 実際にはケースごと、すなわち電源も入れ替わっていますので、
> [&#x30E1;&#x30FC;&#x30EB;&#x30A2;&#x30C9;&#x30EC;&#x30B9;&#x4FDD;&#x8B77;]
> 
> 今回特徴的だったのは、データ化けが4バイト(32bit)単位で化けていたこと、
> また、ビット反転ではなく、まったく違う値になっていたことです。
> 
> 例)
> hd ok_file.tbz >a ; hd ng_file.tbz >b ; diff a b
> 00fff2b0  d4 24 88 dd 69 85 e8 0e  e5 ea d7 9d b4 5b 10 6a
> 00fff2b0  d4 24 88 dd 3c bd 30 90  e5 ea d7 9d b4 5b 10 6a
>                       ~~~~~~~~~~~
> 
> 以下、想像で書いていますので、間違いや考慮不足があったらご指摘いただきたいのですが、
> メモリーエラーなら、どれか1ビット程度が反転するのが普通でしょうし、
> PCIバス上でもおそらくそうでしょう。
> SATAバスは、8B10B+CRCなので突発的な32ビットが化けるとは考えにくい。
> メモリバスは、64bit単位だったと思います。
> 32bit単位というと、CPU内部のレジスタか、それに従属しているであろう
> ソフトウェア(OS)のデータFIFO処理だろうかと予測していたのですが、
> FreeBSDの仕事は、完璧だったようです (^_^)

電源系だったら4バイトだけ化けるというのは、あまり考えにくいかもしれませ
ん。化けるならもっとハデにいっぱい化けるような気がしますし...。

やはり、ハードウェア系の不具合である可能性が高いのでしょうね。


> 情報をいただいた皆様、ありがとうございました。
> 普通に動いていると聞いて、安心しました。
> 今後 RAID1環境の、一候補として、採用していきたいと思います。

追加テストご苦労様でした。
非常に参考になりました。

---
Yoshihiro Hanahara <hanahara @ meiko . co . jp>



メールによる返信