おそるおそる運転再開
この機会にデータドライブも1TBに増強するかと思ったら、ARAIDのカギが見つからん(汗)。どうやら半年前の地デジ化工事の際に、どこかに整理したままと思われる。あそこにあるとばっかり思っていたのが実は無かったというのが一番タチが悪い。
仕方ないので、今回のところは従来の320GBで復旧。結果的にデータ引っ越しの目的でのバックアップは、無駄に時間を使っただけに終わった。
さて、ランレベル3にすると、RAID1の/dev/sdb絡みでやたらエラーが出まくる。
kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
kernel: ata2.00: BMDMA stat 0x24
kernel: ata2.00: cmd c8/00:20:4f:3e:8c/00:00:00:00:00/ee tag 0 dma 16384 in
kernel: res 51/05:20:4f:3e:8c/05:00:1e:00:00/ee Emask 0x1 (device error)
kernel: ata2.00: status: { DRDY ERR }
kernel: ata2.00: error: { ABRT }
kernel: ata2.00: configured for UDMA/100
kernel: ata2: EH complete
kernel: sd 1:0:0:0: [sdb] 625140335 512-byte hardware sectors (320072 MB)
kernel: sd 1:0:0:0: [sdb] Write Protect is off
kernel: sd 1:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn’t support DPO or FUA
このエラー自体は、実は以前から出ていて、私としては「SATA1.5G固定のARAID99-2000にSATA3.0で読みにいってフラれた(のでUDMA100にした)」というのを想像している。
最後のWrite cache: disabedが気になる人もおられるようだが、HDDになりすましているRAIDBOXが、本物のHDD同様のキャッシュメモリを持っているとは考えにくいし(狭義のキャッシュというのは、SATA端子とプラッタの間にあるからこそ意味がある)、OS側で書き出し用のバッファをうまく管理すれば、少なくとも猛烈に遅いということにはならないと個人的に考える。
まあえらそうに書いたが、実はあっさりキャッシュ有効にできる方法があったりして(笑)。
世間でも、カーネルのカン違い?ということで、ちゃんと動いているようなら特に気にする必要はないという見解が大勢だが、なんかやたら頻発するようになったのが気になるのだ。
次回のメンテナンスでケーブルでも換えてみることにするが、ひとまずこのまま走らせて出勤。ただ、もしマザーボードよりもARAIDが早死にしたというのなら、あえてチップセットや拡張SATAボードのRAIDを使わず専用のハードを買った意味がないやんけ。
