5/23,24と多摩センター近くのデジタルハリウッド大学で行われている、Make Tokyo Meeting03に行ってきた。

現地に着くと、やたらとほのぼのした空気で、校舎入り口にある看板を見なければ、ここがデジタルハリウッド大学だとは全く思えない。どこか田舎の小学校にでも紛れ込んだような雰囲気。校舎と体育館と校庭、大きく分けて３カ所で展示が行われているのだが、全体的に校舎の方はアート系、体育館のほうはハード系、校庭は校庭でないとまずいもの(爆発燃焼系だとか走行系)という雰囲気で区分けしたのだろうなという感じ。

アート系は最近仲良くしていただいている多摩美の知人何人かが出展していて、どれも着眼点が面白い。こちとらハード屋なので、そういった着眼点を持てることはちょっとうらやましくもあり、いい刺激になる。

体育館のほうはシリコンハウスさんが来ているということでちょっと期待していたのだが、シリコンハウスさんのところにはあまり面白い物がなかったのが残念であった(後から気づいたのだが、エンジニアのPA-21という新作精密圧着ペンチが出ていたのだった。オレンジのハンドルは見たことがなかったのだが、PA-09,20,PAR-20と持っているのでスルーしてしまっていたのが大変残念・・)。他、この手のライトウェイト電子回路的な業界では有名な通販屋さんが数軒来ていた模様だが、こちらも通販と値段が変わらず、特に購入に至る物は無し。

その後フラフラとうろついてみて、いつも気になる記事をアップされているblog主の方が出展しているのも確認したりしていると、気になるブツが。 60th Luminous Clockといって、デジタル時計ではあるのだが、周囲を取り囲むようにアナログ時計で言うところの秒ごとにチップLEDが付いているというもの。使っているデバイスや構造というよりは、そのLEDの点滅パターンの綺麗さと裏側のパターンの引き回しの綺麗さに惹かれてつい購入(*)、\6,000なり。よく見てみたら、ちょっと洒落た電子デバイスを出していることで以前から知っていた、M-Tech Designさんの製品であったことがわかり、さらに開発者氏(お名前伺いませんでした・・スイマセン)に色々話を伺うことも出来た。なにしろこの配線パターンはこれまでに見たことがない。無償版のEagleで作っているとのことで、一見の価値有りだと思う。

(*)この時計は帰宅後早速ハンダ付け、60個のチップLEDは些か目玉が疲れたものの、およそ1時間ほどで全部品90点ほどの実装を終えて今は仕事部屋の時計として活躍している。随分前に見たような記憶もあったのだが、事実随分前からコミケで売っていたようで。。。

同じく体育館内にあったP板.comのInflowは基板を案内葉書につかうという顧客事例を紹介していたのでそこから担当者氏と会話。Olimexだとかpcbexpressに取られている現状をどうにかということらしいので、月並みではあるが納期を正確に出さない(例えば最短3日最長2週間だとか)ようなオーダーを受けて、隙間を埋めるようにそのバッチを詰めたら安価にならないかと提案しておく。ついでにEagleのbrdファイルをそのまま(ガーバーにせず)受けてくれないかということもお願いしておく。どうも、P板さんとしては中ロット生産の顧客を拾いつつ、もっと小ロット安価生産のほうの顧客も広げていきたいということのよう。

そんなこんなで、その後校庭にでてパルスジェットエンジンが動いているのをぼんやり眺めていたりして、MTM03初体験は終わった。

校舎の方の出展に並べて出せるようなものはどうも作れる気がしないのだが、体育館のほうはハムフェアをものすごくシュリンクしたような、居心地の良い雰囲気であった。こちらのほうに方向を定めて、今度は出展側として参加したいと思う。

まだ終わっていませんがお疲れ様でした。

秋葉原へ出たついでに、先日から調査していたRCR123電池を買ってきた。UltraFireブランドの16340型、880mAh/3.6VのRe/Discharge Protection Curcuit付きのLiIon電池だ。

この電池、カメラや懐中電灯用に用いられる、CR123とほぼ同一の外形でいながら充電可能で、容量もそこそこあるので、ちょっとしたデバイスに使えないかと以前から目をつけていた物。ただ、これまではヤフオク以外の入手経路だと保護回路付きのものが手に入りづらかったのもあって手を出していなかった。

購入元は秋葉原のジャンク屋、三月兎。最近あまりジャンク屋に寄らなかったのだが、しばらく前に友人M氏と久しぶりのジャンク屋巡りをしたときにこういうバッテリーの取り扱いがあることを発見していた。以前寄ったときは在庫の都合か保護回路付きの電池がなかったのだが、昨日寄ったときには目的の物の在庫があった。充電器１台(2本まで同時に充電可能)が2,980円、２本セットの電池が1,500円とそれなりに安価。ヤフオクだともっと安いものもあるので領収書の心配が要らなければヤフオクで買ってもいいかもしれない。

で。それはいいのだけど、これがやたら便利なのは最初の写真のような使い方。千石電商で売っているCR123A電池ボックス(タカチ製でないほう)と組み合わせると、ピン間隔がちょうど秋月の小さいブレットボードの両端にぴったりになり、ワイヤ無しでつけられる3.6V電源として使えるのだ。上のようにLEDを点灯させっぱなしという用途はあまりないが、それでも880mAh(=3.168Wh)も容量があるから１日くらいは放置しておける(*)。試作には大変便利だと言えよう。

(*)放置しておくためにも保護回路付きが大切。

リチウムイオン電池は事故ると下記の映像のごとく燃え上がるので、万人に手放しでオススメできるものではない。というかきちんと対策をもって使えないかぎり手を出すべき電池ではない。だが、きちんと使えばかなりのエネルギー密度で使いやすい電源として使うことが出来る。デバイスの大きさに困っている場合、一度検討してみる価値はあると思う。

追記：三月兎で売っている、銀色のシュリンクフィルムで覆われたUltraFire(保護回路付き)は実測値でおおよそ34mmの長さがある(だから16340なわけだが)。この寸法であれば、CR123Aの寸法とほぼ同じ、同じ電池ボックスも使えるはずだ。だが、国産の普通の電池と比べるとかなり(並べて立てると斜めになっていたりするのが目視ではっきりわかるほど)加工精度は低いので、そのまま入らない電池ボックスがあったりするかもしれない。今回千石で買った電池ボックスもかなりギリギリで、取り付け取り外しにちょっと気をつかう感じであったことを付け加えておく。タカチの製品のほうがまだゆとりがある感じだったので、ギリギリが嫌であればタカチ製品を採用すると良さそうだ。

追記：もっとインパクトのある動画を見つけたので追加しておく。品質の悪い電池を使うリスクはこれくらい高い。

昨日あたり、ついに東京でも初感染者とか。

4/27にコトは重なったりするものというポストをアップしたときには都内の薬局でマスクが売り切れているなんていうことはなかったのだが、今やオークションで10倍もの値段がつく場合もあると聞く。

大切なのは先読みして行動しつつ、気構えないということ。今回のH1N1は今時点では幸いなことに弱毒性というか、重篤な症状となることが少ないようだ。そういえばスペインかぜも第一波は弱毒性だった。その後どうなったかは言うまでもあるまい。

歴史はただ繰り返しがち。そこから人は何を学ぶのだろう。

先日から延々５ポスト(コレ含めて６ポスト)もかけた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 <default  63 sec 255 hd 2 alt 19926 cyl>
          /pci@0,0/pci-ide@1f,2/ide@0/cmdk@0,0
       1. c5t0d0 <ata-wdc wd10eads-00l-1a01-931.51gb>
          /pci@0,0/pci8086,244e@1e/pci1095,3124@0/disk@0,0
       2. c5t1d0 <ata-wdc wd10eads-00l-1a01-931.51gb>
          /pci@0,0/pci8086,244e@1e/pci1095,3124@0/disk@1,0
       3. c5t2d0 <ata-wdc wd10eads-00l-1a01-931.51gb>
          /pci@0,0/pci8086,244e@1e/pci1095,3124@0/disk@2,0
       4. c5t3d0 <ata-wdc wd10eads-00l-1a01-931.51gb>
          /pci@0,0/pci8086,244e@1e/pci1095,3124@0/disk@3,0
       5. c6t0d0 <ata-wdc wd10eads-00l-1a01-931.51gb>
          /pci@0,0/pci8086,244e@1e/pci1095,3124@1/disk@0,0
       6. c6t1d0 <ata-wdc wd10eads-00l-1a01-931.51gb>
          /pci@0,0/pci8086,244e@1e/pci1095,3124@1/disk@1,0
       7. c6t2d0 <ata-wdc wd10eads-00l-1a01-931.51gb>
          /pci@0,0/pci8086,244e@1e/pci1095,3124@1/disk@2,0
       8. c6t3d0 <ata-wdc wd10eads-00l-1a01-931.51gb>
          /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
        !<cmd>     - execute <cmd>, 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
        !<cmd>     - execute <cmd> , 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、マシンごと再起動がかかった。

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

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

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

メモリがきちんと動くことを検証したのち、再度下記のテストを行った。やはりディスクの電源を突然抜くと、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はしない、という方向でいけば、とりあえず最悪のデータロスは防げそうな気配。高負荷時に割り込みを取りこぼすという件は再現していないので再現してから考える。

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

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

これまで使っていたIODATAのLANTANK GIGAだが、最近sata3(3本目のディスク)がさわってもいないのに取り外されてしまう問題が頻発していた。おそらく接点が痛んできたというような問題なのだろうが、RAID5で１本抜けてしまうのは致命的すぎる。そんな状態で数ヶ月我慢していたのだが、もう我慢の限界、自前でNASを作ることにした。このポストではその設計～結果について書こうと思う。気にした点は容量、消費電力、騒音、だ。

■容量

容量は最近は1TBクラスのHDDが異常に安いのでそれを大量に使うことにして解決する。ファイルシステムは色々検討したのだが、Linux/RAID6よりはopensolarisにzfs(raidz2)のほうが安定しそうに思えたのでそれを使うことにした。使い慣れているFreeBSDにもzfsはポーティングされているのだが、過大な負荷を掛けるとpanicするという情報もあったため、泣く泣くopensolarisを選定している。ハードウェアRAIDをあえて選定していないのは、コストの面もあるがそれに加えて運用方法がハードウェアによって独特で、学習コストが無駄に高いことをきらってのこと。運用ツールがOSのバージョンにかなり依存しているケースもあって、そうなるとかなり面倒なことになってしまう。それに比べると最近の速いハードウェアにソフトウェアRAIDであれば、運用方法もわかるし、大きなトラブルでアレイごと他のコンピュータに移す必要が出たりというレアケースにも対応しうるということは、実はかなり大きい。

さて、HDDを大量につなぐとなると困るのはインタフェイスだ。色々調査したのだが、１枚の拡張ボードでSATAを8ポートとなると敷居が高く、製品がかなり絞り込まれてまい、殆どがエンタプライズ用途向けばかりになってしまう。その手の製品は専用ドライバを要求したりで前述の運用が面倒という 話題をぶり返してしまいかねない。そういうことになっては馬鹿馬鹿しいことこの上ないので、玄人志向のSATA2I4-LPPCIというSiliconimge Sil3124を用いたSATA4ポートの素直なボードを2枚使うことにした(*)。SATA300は300MB/sec、PCI(32bit/33MHz)は133MB/secとHDDのインタフェイスの方が速いのだが、どうせファイルサーバであってGbE(=1000Mbps=125MB/sec)以上の速度は必要ないため、割り切ってしまうことにする。

(*)この手のディスクインタフェイス系デバイスはBootROMが喧嘩することがある。そのため、同じモノであっても２枚を同時に使うことが出来るか不安だったのだが、これも「出来る」というレポートを見つけることが出来たので後は自己責任ということで買ってしまった。結果、少なくとも私の構成では２枚同時に問題なく認識させることが出来ている。

HDDそのものは、容量を優先してSeagateのST31500341AS(1.5TB/7200rpm)を使おうかとも考えたが、後述する騒音問題が大きくなってしまう不安と、システム全体の費用が増えることを嫌って、Western Digital WD10EADSを10本(うち8本で6TBのraidz2を構築、1本はつないでおいてホットスペア、1本は完全に予備)を選定した。

■消費電力

消費電力は、当初atomプロセッサを使うことで解決しようと考えていたが、実はデスクトップボードに仕立ててあるatom搭載マザーボードは割と電気を食う(システム全体で40W以上という例もある様子)上、実は最近の45nmプロセスで製造されたプロセッサと、システム全体では激しく違うということもないということが友人M氏の指摘でわかった。それに加えて、atom搭載マザーボードの部品選定は、競合が少ないこともあっていまいち単体マザーボードより贅沢さが足りない(固体電解コンデンサが少なめだとか)ので、最終的にはGIGABYTEのG31M-ES2LとDualCore PentiumE5200を使うこととした。

■騒音

騒音は、HDD自体がある程度うるさいものである以上どうしようもないのだが、それでも静かにしたい。ということで前述の通り5400rpmのWD10EADSを選定したわけだがこれが大正解。ケースを開いたまま8本すべてがスピンアップしても殆どわからないくらいの音しかしない。さすがにアクセスがあったときのヘッド動作音は聞こえるので、そこだけは今後対処しなければと考えている。

構築と結果

あちこちのzfs情報を掲載しているサイトを巡りつつ、下記の通りpoolを初期化した。

root@melongena:~# zpool create tank0 raidz2 c5t0d0 c5t1d0 c5t2d0 c5t3d0 c6t0d0                                                     c6t1d0 c6t2d0 c6t3d0

構築後の容量は下記の通り。

root@melongena:~# zpool status
  pool: rpool
 state: ONLINE
 scrub: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        rpool       ONLINE       0     0     0
          c3d0s0    ONLINE       0     0     0

errors: No known data errors

  pool: tank0
 state: ONLINE
 scrub: scrub completed after 0h0m with 0 errors on Sat May  2 05:52:28 2009
config:

        NAME        STATE     READ WRITE CKSUM
        tank0       ONLINE       0     0     0
          raidz2    ONLINE       0     0     0
            c5t0d0  ONLINE       0     0     0
            c5t1d0  ONLINE       0     0     0
            c5t2d0  ONLINE       0     0     0
            c5t3d0  ONLINE       0     0     0
            c6t0d0  ONLINE       0     0     0
            c6t1d0  ONLINE       0     0     0
            c6t2d0  ONLINE       0     0     0
            c6t3d0  ONLINE       0     0     0

unos@melongena:~# df
Filesystem           1K-blocks      Used Available Use% Mounted on
rpool/ROOT/opensolaris
                     152562045   2383869 150178176   2% /
swap                   2176776       324   2176452   1% /etc/svc/volatile
/usr/lib/libc/libc_hwcap1.so.1
                     152562045   2383869 150178176   2% /lib/libc.so.1
swap                   2176484        32   2176452   1% /tmp
swap                   2176544        92   2176452   1% /var/run
rpool/export         150178195        19 150178176   1% /export
rpool/export/home    150178195        19 150178176   1% /export/home
rpool/export/home/unos
                     150191281     13105 150178176   1% /export/home/unos
rpool                150178248        72 150178176   1% /rpool
tank0                5732278181        41 5732278141   1% /tank0

この後、zvol と iSCSI と NTFS と zfs snapshotを参考にしたりしつつ、iSCSI Targetとして1000GBの領域を公開、Windows端末(ThinkPad T60/Core2Duo2.0GHz)からHDBENCH3.30でベンチマークを取ってみた。結果、Read 82,914kb/sec、Write 71,160kb/sec、FileCopy 18,423kb/secと、家庭用NASとしては十二分に早いと言える数字が出た。

(*)しかしながら、このいい数字は常にでるわけではなく、試しに2000MBのサイズで試したところ、Writeが20MB/sec程度にまで落ち込んだ。転送速度グラフをみるとピークは高いものの安定せず、時々転送速度がかなり落ち込むのが原因らしい。原因がどこにあるのかは追って調査中である。

今後、無理矢理ディスクを抜いてみたりというトーチャーテストを行った上、問題がなさそうであればsamba等必要なパッケージ類を突っ込んで、新NASの出来上がりとなる。今のところ目下の課題は使っているケースへのHDD固定方法、ではあるのだが…。(^^; この上3台くらい入るかと思うと気が重い。。。。

余談。途中で気づかれた方もいるかと思うが、新NASの名前はmelongenaにした。茄子の学名である。

追記： read/writeの数字、そのときの実測ではあるのだが、iostatでHDDの速度を見ていると、ピークでも１発あたり10MB/sec程度しか出ていない。これを上限とする限り、ピークでも読み出しは(パリティは飛ばして読んでいるとしても)80MB/sec、書き込みはパリティ分実速度から落ちるので60MB/secが限界のはず。zfsはメモリに随分キャッシュするのでその関係でこういう速度が出ているのだろうと思う。

しかしWD10EADSのような最近の単体で速度がでる玉を使っておいて10MB/sec。さすが33MHz32bitPCIに4つもSATAをぶら下げるだけのことはある、本当に、遅い。