先日から延々５ポスト(コレ含めて６ポスト)もかけたNASだが、ついに落ち着いた。先日からまた延々zpool scrubを掛けて掛けてエラーが出たらケーブルを取り替えての繰り返し、結局３本の不良ケーブルが混じっていたようであった。

結局さんざん苦労した代償として、下記のことに注意しておかねばならない、という教訓を得た。

• NASとするコンピュータのメモリはmemtest86などのツールできっちりテストしておく。出来れば(というかほぼMUST)ECC付きメモリにすること。
• SATAケーブルは良質な物を選ぶこと。１本100円のような安売りのものを買わないこと。(大変時間を無駄にした・・・)
• 構築後、きっちり負荷を掛けたり引っこ抜いたりしてテストすること。データを失ってからでは遅い。(サーバなら最低数日のエージングは当然だが)

特に１点目のメモリ問題は怖い。私の場合、memtest86で１周できないメモリが刺さっていたがために、zfsのraidz2領域すべてが完全に修復不能なレベルでつぶれてしまった。特に酷いメモリをつかんでしまったのだろうとは思うが、同じことをクリティカルな要件で起こしてしまってはしゃれにならない。家庭用であったとしても、データを失ってしまえばもうそのデータは二度と帰ってこない。そのことを考えたら一晩memtestを走らせておくくらい軽いものだろう。

最終的にかかったコストは、HDDが予備含め10本で75,000円ほど、M/B、メモリ、CPUで20,000円ほど、SATA I/Fが２枚で15,000円ほど、ケースが12,000円ほど(これは無茶苦茶な破格だった)と、ケースのファンがうるさすぎて全部交換したので5000円ほど、合計で127,000円程度(システム用HDDはジャンク箱に突っ込んであった160GBを流用)で収まった。ダブルパリティで保護された6TBの領域を持つNASとしてはきわめて安価だといえよう。

次は各種サービスをsolaris containerで動かしていこうと思う。opensolarisのポテンシャルの高さに、気がついたら全然NASでなくなりつつある。

これまでのポストの続き。引き続きデータを大量に突っ込んだりしてテストしているのだが、大量データ投入中、下記のようなエラーが連続して発生した。

-略-
May 10 07:23:09 melongena       Error for Command: write(10)               Error Level: Retryable
May 10 07:23:09 melongena scsi: [ID 107833 kern.notice]         Requested Block: 52263759                  Error Block: 52263807
May 10 07:23:09 melongena scsi: [ID 107833 kern.notice]         Vendor: ATA                                Serial Number:
May 10 07:23:09 melongena scsi: [ID 107833 kern.notice]         Sense Key: Aborted_Command
May 10 07:23:09 melongena scsi: [ID 107833 kern.notice]         ASC: 0x8 (LUN communication failure), ASCQ: 0x0, FRU: 0x0
May 10 07:23:10 melongena scsi: [ID 107833 kern.warning] WARNING: /pci@0,0/pci8086,244e@1e/pci1095,3124@0/disk@0,0 (sd1):
May 10 07:23:10 melongena       Error for Command: write(10)               Error Level: Retryable
May 10 07:23:10 melongena scsi: [ID 107833 kern.notice]         Requested Block: 52271544                  Error Block: 52271752
May 10 07:23:10 melongena scsi: [ID 107833 kern.notice]         Vendor: ATA                                Serial Number:
May 10 07:23:10 melongena scsi: [ID 107833 kern.notice]         Sense Key: Aborted_Command
-略-

このエラーを調べると、一般的にはディスクが壊れる前兆として現れるらしいのだが、formatでディスクまるごとスキャンしてもエラーなし。

root@melongena:~# format	
Searching for disks...done


AVAILABLE DISK SELECTIONS:
       0. c3d0 
          /pci@0,0/pci-ide@1f,2/ide@0/cmdk@0,0
       1. c5t0d0 
          /pci@0,0/pci8086,244e@1e/pci1095,3124@0/disk@0,0
       2. c5t1d0 
          /pci@0,0/pci8086,244e@1e/pci1095,3124@0/disk@1,0
       3. c5t2d0 
          /pci@0,0/pci8086,244e@1e/pci1095,3124@0/disk@2,0
       4. c5t3d0 
          /pci@0,0/pci8086,244e@1e/pci1095,3124@0/disk@3,0
       5. c6t0d0 
          /pci@0,0/pci8086,244e@1e/pci1095,3124@1/disk@0,0
       6. c6t1d0 
          /pci@0,0/pci8086,244e@1e/pci1095,3124@1/disk@1,0
       7. c6t2d0 
          /pci@0,0/pci8086,244e@1e/pci1095,3124@1/disk@2,0
       8. c6t3d0 
          /pci@0,0/pci8086,244e@1e/pci1095,3124@1/disk@3,0
Specify disk (enter its number): 1
selecting c5t0d0
[disk formatted]
/dev/dsk/c5t0d0s0 is part of active ZFS pool tank. Please see zpool(1M).


FORMAT MENU:
        disk       - select a disk
        type       - select (define) a disk type
        partition  - select (define) a partition table
        current    - describe the current disk
        format     - format and analyze the disk
        fdisk      - run the fdisk program
        repair     - repair a defective sector
        label      - write label to the disk
        analyze    - surface analysis
        defect     - defect list management
        backup     - search for backup labels
        verify     - read and display labels
        inquiry    - show vendor, product and revision
        volname    - set 8-character volume name
        !     - execute , then return
        quit
format> analyze


ANALYZE MENU:
        read     - read only test   (doesn't harm SunOS)
        refresh  - read then write  (doesn't harm data)
        test     - pattern testing  (doesn't harm data)
        write    - write then read      (corrupts data)
        compare  - write, read, compare (corrupts data)
        purge    - write, read, write   (corrupts data)
        verify   - write entire disk, then verify (corrupts data)
        print    - display data buffer
        setup    - set analysis parameters
        config   - show analysis parameters
        !   - execute  , then return
        quit
analyze> read
Ready to analyze (won't harm SunOS). This takes a long time,
but is interruptable with CTRL-C. Continue? yes

        pass 0
   1953525042

        pass 1
   1953525042

Total of 0 defective blocks repaired.

もしかするといくつか前のポストに書いた、si3124ドライバに重負荷をかけると割り込みを落とす、という問題が顕在化しただけかもしれないが、zpool scrubをかけても異常は検出されなかったのでとりあえず放置することにする。

余談だが、zfsの何がいいかって、zfs情報をexportせずにOSそのものをクリーンインストールしてやったあと、zpool import一発でアレイ構成情報をすべて復旧できること。ファイルも失われないし、アレイの設定情報をメモする必要もない。繋がっているドライブの位置が変わっても自動的に認識してくれる。つまり私のような人間には大変向いているファイルシステムだということだ。素晴らしい。

続く。

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

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

しかしひどい話だなぁ。

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

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