なんか昔書いたけどかなり適当だったので、ちゃんと今回は書く。

今回は以下のようなシステムレイアウト。

RAID0のアレイ1 -+- システムで予約済みのパーティション
                +- Windows7のインストールパーティション
                +- データ用パーティション

RAID0のアレイ2 -+- Ubuntu 10.04のインストールパーティション
                +- swap
                +- Debianのインストールパーティション

アレイ1のMBRにbootmgrを、アレイ2のMBRにgrubをインストールしてある。

bootmgrからはWindows7、grub4dosのエントリを作成、grub4dosはアレイ2のMBRにチェインロードするようにし、Linux系OSの起動はアレイ2のgrubから行う。

まず、Windows7を起動。
grub4dosを入手し、展開する。
ディスクの管理から、システムで予約済みの領域をマウントする。
そのパーティションのルートにはbootmgrがあるはず。
環境によってはすでにマウント済みの領域にあるかもしれない。
そこにgrub4dosのgrldr.mbrをコピーする。
menu.lstを同じフォルダに作成。
内容を以下のように記述。

title linux
rootnoverify (hd1)
chainloader (hd1)+1

これでgrub4dosからは二つ目のアレイのMBRにチェーンロードする形になる。
そこからはgrubが呼び出されるのでそっちに任せる。

bootmgrからgrub4dosを呼び出すエントリを作成する。
コマンドプロンプトを管理者権限で起動して、以下を入力。
{ID}はGRUB4DOSエントリのID。

   bcdedit /create /d "GRUB4DOS" /application bootsector
   bcdedit /set {id} device boot
   bcdedit /set {id} path grldr.mbr
   bcdedit /displayorder {id} /addlast

これでbootmgrからgrub4dosを呼び出せる。
	

前のエントリでICHxRでのRAIDについてのIntelからのお話を書いたが、今度は一般的な話。

RAIDってのは複数のディスクをひとまとめにして、速度と冗長性を確保する技術だ。
ひとつのデータを複数のディスクにまたがって記録することで実現する。

とまあ、とっても当たり前の話をする。
さて、RAIDにもいくつかの種類があることはご存知だろう。
ここではミラーリングは問題の対象外であるため、RAID1は除外する。

問題が発生しうるのは、RAID0やRAID5、あるいはその他複合RAIDである。

一番シンプルなデータ分散書き込み構成であるディスク2枚によるストライピング構成を考える。

Windows 2000以降のNTFSファイルシステムにおける既定のアロケーションユニットサイズ（クラスターサイズ）は、通常4KBになる。（ディスク領域が2G未満であったり、16TBを超えるディスクからは既定のアロケーションユニットサイズが変わってくるが）
アロケーションユニットサイズは、ファイルを保持するのに割り当て可能な最小ディスク領域となる。
1byteのファイルであっても、アロケーションユニットサイズが4KBなら、実際にディスク上で占める領域は4KBとなる。

ここで、ディスク2枚のストライピングにおいて、アロケーションユニットサイズが4KBである場合、実データは各ディスクに2KBずつに分散して記録される。

さあ、ここであれ？って思わないでしょうか。
read modify write の発生が頭をよぎります。

大嘘でした。
strip size（ストライプサイズ）ごとにデータを分散させるように書き込むため、stripe sizeが128Kの場合は256Kの書き込みなら同時に二つに書き出すけど、4Kなら片方のディスクしか使わない。

とりあえず、先日、wd20ears-00mvwb0を2枚ぽちった。
で、IntelのRapid Storage TechnologyのドライバでRAID0組みました。
Windows7とりあえず入れてみました。
で、上記のような意識があったので、実際のところパフォーマンスに影響があるのかどうか、アロケーションユニットサイズを変えてCrystalDiskMarkを何パターンか走らせてみた。

512byte

2048byte

4096byte

8192byte

16KB

64KB

シーケンシャルアクセスではアロケーションユニットサイズの影響はないことがみてとれる。
4KBのランダムリードでも差はないようだ。
512KBのランダムリードでは8192byteまでは速度向上がみられ、それ以上のアロケーションユニットサイズではスケールアップしないようだ。
4KBのランダムライトでは2048byteまでと4096byteで大きく違い、それ以上はスケールアップしない。
512KBのランダムライトでは4096byteまでと8192byteで大きく違い、16KBで少々のスケールアップがみられる。

さて、この結果をどう考えるか、いろいろ考えていたんだけども、4KBのランダムライトではアロケーションユニットサイズ4KBと8KBで差が出なかったのでいまいち結論付けに困っている件。

512KBのランダムライトではread modify writeが発生していることによる速度差だと思う。
4KBだとおきないのかっていうと、おきると思ってたんだけどなぁ。
ちなみに、ランダムライトの4Kは4000byteで、クラスタサイズのほうは4096byte。
書き込み単位がクラスタサイズに収まっていることが関係しているんだろうか？
stripe sizeを今回128Kで構築しているので、read modify writeは発生しない。
とすると単なるクラスタサイズによるスケールアップとみるのが妥当か。

とりあえず、512Kのランダムライトのパフォーマンスの差を見る限り、4KB物理セクタのHDDディスク2枚でのストライピングを構成する際には、アロケーションユニットサイズを8192byteなり16KBなりにしておいたほうがいいだろう。