パスワードを忘れた? アカウント作成
469983 journal

kmraの日記: USBメモリでものすごくRandom Readが速いRAID(妄想) 12

日記 by kmra

今やReadyBoost対応の高速USBメモリでも500円/GB。
4本とか8本束ねてRAID0したらものすごく速いファイルサーバができそう。
Flashメモリの書き換え回数対策は通常のHDDとRAID1。HDDの方は通常時Write OnlyでWriteをシーケンシャル順に行うファイルシステムを使う(たとえばnilfsとか)。

PQI U339 pro 2GのCrystalDiskMarkのスコア
Sequential Read : 24.157 MB/s
Sequential Write : 14.529 MB/s
Random Read 512KB : 24.07 MB/s
Random Write 512KB : 7.703 MB/s
Random Read 4KB : 6.016 MB/s
Random Write 4KB : 0.123 MB/s

これを8本RAID0したときの妄想スコア(USB2.0の限界を超えるので複数USB Hostを用意したとして)
Sequential Read : 193.256 MB/s
Sequential Write : 116.232 MB/s
Random Read 512KB : 192.56 MB/s
Random Write 512KB : 61.624 MB/s
Random Read 4KB : 48.128 MB/s
Random Write 4KB : 0.984 MB/s

元のRandom Write 4KBが弱いのでそれなりですが、Random Read 4KBでも48MB/sはものすごく速そうじゃないですか?
(普通のHDDの例 Random Read 4KBは1.6MB/s程度)
Random Writeも512KBまでなら61MB/s。組み合わせるnilfsも4KB以上のRandom Writeで60MB/s以上でる。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 元のRandom Write 4KBが弱いのでそれなりですが、Random Read 4KBでも48MB/sはものすごく速そうじゃないですか?

    速いだけでなく、消費電力もかなり低いと思います。

    ただ、FlashROMは壊れたときの検出がほとんど無いに等しい製品ばっかりなので、Raid5か6にした方が良いかと…。あと予防交換戦略をきっちり立てておく必要があると思います。
    # Raid 1-0 にして、Mirror をわざと「数ヶ月遅らせて」作ると言うのも手ですね。
    --
    fjの教祖様
    • 速いだけでなく、消費電力もかなり低いと思います。
      そうですね。消費電力/性能でいくとかなりいい成績になりそうです。

      ただ、FlashROMは壊れたときの検出がほとんど無いに等しい製品ばっかりなので、Raid5か6にした方が良いかと…。
      壊れ対策は通常のハードディスクとのヘテロRAID、FSもヘテロで行きましょう(CD-ROMの上に重ねるFSが過去にありましたが、あれに似た感じだと思っています)。
      ところで、okkyさんのコメントは、USB Flashはエラーが起きても素知らぬふりをして壊れたデータを返してしまうということでしょうか?

      親コメント
      • USB Flashはエラーが起きても素知らぬふりをして壊れたデータを返してしまうということでしょうか?

        それも結構あるそうです。主にコントローラー側の手抜きなんでしょうが。

        それ以上に、ブロック単位で雪崩をうって壊れるのでチェックサム程度だと役に立たない、とも聞きます。つまり、ブロックの中でも「こっちが1ビット」「あっちが1ビット」という具合に徐々に壊れていくと言うよりは(それならエラー検出さえちゃんとして、壊れたらスペアに入れ替えれば間に合う)、ある書き換えのタイミングでいきなり「ガーーー」っと1blockの10%ぐらいがいきなり破綻する事があるそうです。品質管理が良くできてるんだか何なんだか…。

        壊れると片側に寄る(1->0なのか 0->1 なのかはモデル依存ですが)性質を持っています。つまり、1を覚えているはずのものが0を返すケースは判るが、0を覚えているはずの場合は壊れていようが正常だろうが0を返すので、それで発見されなかった故障が一気に見えてくるのかもしれません。

        とりあえず、書き終わってもいきなりサーバ側のデータを消さないで、しばらくしてからデバイスキャッシュをスキップする形で読み直して、内容を確認する…なんて機能が欲しくなります。
        --
        fjの教祖様
        親コメント
        • USB Flashはエラーが起きても素知らぬふりをして壊れたデータを返してしまうということでしょうか?

          それも結構あるそうです。主にコントローラー側の手抜きなんでしょうが。
          それは明らかに手抜きですね(笑)

          Flashメモリデバイスの仕様書にはECCつけて使えと書いてあります。まじめなコントローラはちゃんとECCをつけて管理しているはずです。
          デバイスとしては、ECCや管理に使うために512Byte毎に16Byteあるいは2KByte毎に64Byteの領域があります。
          最近のものは4KB+218B(?)のもの(TC58NVG4D1DTG00 東芝16Gbit NAND FLASH [toshiba.co.jp])がありますが、何でこんなに半端なんでしょう(笑)

          とにかく、この領域にECCやら管理情報を入れるわけです。256Byteで管理領域も含めて8Byteですからメインメモリのような強力なECC(8Byte毎に1Byte)はつけられませんが256ByteをブロックとしてECCをつければかなりのエラー検出能力、訂正能力を持たせることができるはずです。

          ある書き換えのタイミングでいきなり「ガーーー」っと1blockの10%ぐらいがいきなり破綻する事があるそうです。
          これは危険ですね。信頼性を考えてHDDにミラーリングしましょう。
          親コメント
          • これは危険ですね。信頼性を考えてHDDにミラーリングしましょう。

            HDDにミラーリングする場合、Raidコントローラーは「データの二重化が終わってから」でないと書き込み完了を返さないような気がします。つまりHDDに足を引っ張られてしまい、全然スピードが出ないのではないかと思うんですが…。

            Random Read であればすばらしい性能が出ると思うんですが…。
            --
            fjの教祖様
            親コメント
            • HDDにミラーリングする場合、Raidコントローラーは「データの二重化が終わってから」でないと書き込み完了を返さないような気がします。つまりHDDに足を引っ張られてしまい、全然スピードが出ないのではないかと思うんですが…。
              そこは

              HDDの方は通常時Write OnlyでWriteをシーケンシャル順に行うファイルシステムを使う(たとえばnilfsとか)。
              ですよ。

              とにかく、あくまで妄想なので実証するまでは「すげえ」とは言ってもらえないわけで
              親コメント
              • あぁ、なるほど。

                それ、単純にそれだけだと上手くいかない。

                HDDの場合 head seek がなくても「セクターがヘッドの真下に来るまでの時間」分だけ待ちが入る。例えば15000rpm だとして1周4msecかかる。で、大雑把に言って「代替セクター」が 90度分存在するので残り270度。

                一回の write で何度分書くのかにも依存しますが(そして、それは外周から勘定してどれぐらい内側のトラックなのかにも依存しますが)、x度だとすると( 0 < x < 270 )

                1. 運よく角度がぴったりだった場合、待ち時間0になる。ただし、確率は0となる。
                2. ヘッドの真下に、x度の内書きたい部分の一部が引っかかっていると「丸々1周かかる」
                        (例えば30度分書きたくて、10度のところから書き始めると、20度分は即座に書ける
                          が、その後ずーっと待って最初の10度分を書き終わると、platter は丁度1周している)
                        こうなる確率は x/360。
                3. ヘッドの真下にx度の内書きたい部分が全く存在しない場合、x度の部分が真下に
                        来るのを待って書き始めることになる。完全にランダムなタイミングで書き込みが
                        発生すると仮定すると、平均して (360 - x)/2 度 分だけ待つことになる。その後
                        x 度分書くための時間がかかる。故に (180 + x/2) 度分の時間がかかる。
                        この確率は (360-x)/360


                という待ち時間が発生する(xについて方程式を解いて、x を 0 - 270 までの値で積分するのは面倒くさいのでやってちょ… :p 積分した後でも3次式だけどさ)。

                FlashROM はこの待ち時間が丸々ありませんので、その分だけ待ち時間が発生する事になります。で、この待ち時間は普通のHDDに普通に書いている場合の待ち時間と一緒なので…ようするにただ単にHDDに書いているのと同じ性能になっちゃいます。

                # Raid0 の分だけ速くなるとは思いますが、単なる Raid0 の連続書き込み程度にしかならない。

                .

                結局、FlashROM とペアを組んで速くなるのは『FlashROM だけ』なんです。

                FlashROM の将来 [srad.jp]という日記に書きましたが、FlashROM の場合 Raid1 にしておいて、意図的に片側を「少し経ってから作成する」(というか、片側を意図的にエージングかけて壊れやすくしておく)事で、両系が同時に破損する可能性を回避するしかないと思います。
                --
                fjの教祖様
                親コメント
              • お返事遅くなってしまってすみません。

                なんと、その道のトップの会社の方ではないですか。素人の妄想におつきあい下さいましてありがとうございます。

                まず、私の説明に用語的な誤りと、説明が十分ではない箇所がいくつかありましたので訂正させてください。前提を間違えていると解があわなくなりますので。

                私が提案する(USB)FLASHメモリ+HDDを使ったシステムは、FLASHとHDDの間がRAID構成ではありません。

                複数のFLASHメモリをRAID0で一つに見せる→FRAID0とします
                FRAID0に通常のファイルシステムを載せます(WinならNTFS、FreeBSDならUFS2?)
                これをF0とします。

                複数のHDDをRAID0で一つに見せる→HRAID0とします
                HRAID0をnilfsでフォーマットします。これをH0とします
                H0はF0のバックアップ目的に使用します。

                F0とH0をunionFSでまとめます。WriteはF0とH0の両方に行い、ReadはF0だけから行います。但し、F0からのReadがエラーの時はH0から読み出します。

                F0はランダムアクセスのR/W共に高速です。
                H0はランダムアクセスのWが高速です(nilfsがlogファイルシステムなので、FS上のランダムアクセスWがシーケンシャルWになる)。

                Read時はF0のみなので高速。
                Write時はF0もH0も両方書き込む必要がありますが、どちらも高速。
                だからHDDをFLASHのバックアップとして使っているのに、全体として高速という訳です。妄想レベルなので、まだご指摘がないところに穴があるかもしれません。

                (もっと単純にF0とH0をRAID1構成として書き込みは両方、読み出しはエラーがなければF0とします。これをnilfsにすれば良いのかもしれません)

                さて、ここから先が欠点です。
                私の案ではFLASHメモリのバックアップとして容量単価が安いハードディスクを使用することができると思うのですが、FLASHメモリが壊れたときにはただのHDDに見えてしまうので一気に性能が低下します。壊れたときでも性能があまり落ちないようにするためには、FLASHメモリでRAID1/5/6の構成として結局速いデバイスばかりでくむ必要があります。

                次に、unionfsが必要で生ディスクとしてはみえないためUnix系は大丈夫でも、Win系はたぶん無理ということです。頑張って使うならVMWareを使うか、ネットワークdiskになると思います。

                私の最初の投稿での間違いは「書き換え回数対策」と書いてある箇所がありますが、書き込みをFLASHメモリにしないというのはないので間違いです。お詫びして訂正いたします。

                okkyさんのコメントに返すところまで到達していないのですが今日は遅くなってしまったのでまずは私の妄想diskの詳細までです。明日以降またコメントいたします。
                親コメント
  • by TarZ (28055) on 2008年04月12日 21時02分 (#1328735) 日記
     USBは、1つのホストコントローラで480Mbps(実効で30~40MB/sあたり?)のバスを共有しているので、多分複数挿ししても速度の上限があると思います。単体でのシーケンシャルリード24MB/sは、かなり上限に近いんじゃないかと。

     複数のホストコントローラで分ければ早くなるかも。
    • by kmra (33703) on 2008年04月12日 21時57分 (#1328749) 日記

      USBは、1つのホストコントローラで480Mbps(実効で30~40MB/sあたり?)のバスを共有しているので、多分複数挿ししても速度の上限があると思います。
      その通りです。だから

      (USB2.0の限界を超えるので複数USB Hostを用意したとして)
      ですよ。

      Hi-Speed USBの転送速度の上限はUSB-COLUMN [mcn.oops.jp]によるとエンドポイント当たりの最大データ転送速度が53MB/sです。
      しかしこの値には、Control転送の予約分が20%、制御用データの付加分が入っていないものと思われるため、実際の上限はこれより下になります。
      実測で30MB/sまでは行くみたいですね。

      今回狙っているRandom Readの速度向上に関しては限界まで行かないのでご安心を。
      USBメモリとHDDをRAIDにしてシーケンシャルReadの時はHDDを読みに行くとよいかもしれないです。
      親コメント
      • by TarZ (28055) on 2008年04月12日 22時14分 (#1328752) 日記

        (USB2.0の限界を超えるので複数USB Hostを用意したとして)
         おっと、見落としてました。すいませぬ。

        今回狙っているRandom Readの速度向上に関しては限界まで行かないのでご安心を。
         ランダムリードだとバスではなくてメモリ側がネックになっていそうなので、並列で改善しそうですね。
        親コメント
        • by kmra (33703) on 2008年04月12日 22時57分 (#1328772) 日記
          今調べてみたら、Intel X48 Express chipsetはEHCI(USB2.0のホスト)が2個入っているとのこと。
          EHCI1ポートにつきUSBメモリ4個だと本体だけで大丈夫ですね。EHCI2個あればRandom Read 4KBが48MB/sに近いところまでいけそうです。

          シーケンシャルReadのときのトップスピードが足りなければUSB2.0カードの増設が必要ですね。
          USB2.0のカードを2枚刺せばEHCI1ポートにつきUSBメモリ2個ですから妄想値の約200MB/sは無理にしてもPeakで100MB/sぐらい行きそうです。

          PCI ExpressのUSB2.0カード [sonnettech.com]だとPC側のバスが飽和することもないのでPCIより性能が出やすいと思いますが、まだ1万円とちょっと高いみたいですね。
          親コメント
typodupeerror

一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy

読み込み中...