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

-略-
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付きメモリがない環境では使用してはいけない、、のではないかと思うのだがどうだろうか。安定して動作しているように見えたメモリが、気温や振動や電源装置のコンデンサの経年劣化による電圧変動などで正常に動作しなくなるというのはよくある話なのだが。。

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

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

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

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

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

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