ReFSを使う

以前の記事に書いたようにデータディスクをWindows 8.1の記憶域スペース (Storage Space) を使った双方向ミラーに移行した。この場合NTFSに加えてReFSが使えるのだが、ATTOでパフォーマンスを調べてみて驚いた。

Writeパフォーマンスが 16 IOPS以下・・・ これじゃあ使えないよね、と言うことでReFSは諦めた。

しかし個人で扱うストレージもTBで測るのが当たり前になった今、できれば高信頼性ファイルシステムが使いたい。zfsも試したのだがこれもイマイチだ。Windowsでは直接扱えないのでVM上のLinuxにzfs-fuseとsambaをインストールして仮想ファイルサーバーにしてみたのだが、案の定オーバーヘッドが大きくCPU負荷が高い。また上のReFS程ではないにしてもzfsそのもののWriteパフォーマンスが良くない。

仮想環境の影響もあるだろうし、商用版zfsとは違う可能性もあるから、一概に「zfsはダメ」と言うのは不適切かもしれない。しかしWindowsのローカルファイルシステムと同じように使うのにこの方法以外は思いつかないから、他に評価のしようがない。

ここで少し見方を変えてみた。ReFSはWindows Server 2012および同R2にも搭載されている。全世界で販売されているサーバー製品である。さすがに 16 IOPSは無いんじゃあないの。何か間違えたのかな、と思い直し、パフォーマンスを測りなおしてみた。

/*-----------  -----------*/

実際の利用に即したテスト

実際にコンピューターを使っていて、データディスクのパフォーマンスが一番効く場面の一つがデータの移し替えではないだろうか。Seq. Writeに相当する数字を測るため、約23GBのファイルを別のディスクからReFSのパーティションにコピーしてみた。

平均80MB/s程度のスピードだ。Windowsのキャッシュは助けになっていないはずなので、これはReFSの正味のWriteパフォーマンスだと考えてよい。

ReFSに使っているWestern DigitalのGreenは単体ディスクのSeq. Writeパフォーマンスが100MB/s程度だ。その約80%のスピードが出ているので、これなら不満は無い。CPU負荷もNTFSの場合とあまり差がない。CDM (Crystal Disk Mark) で測った結果も似たようなものだ。

最初に掲載したATTOの結果は一体どうなっているのだろう。正確には分からないが、ReFSがチェックサムを使って信頼性を確保していることに関係しているのかもしれない。

ReFSのチェックサム

ReFSはメタデータについては常に、ユーザーデータについてはオプションで「整合性ストリーム」と指定されたものについてチェックサムを取ることによりデータの破損を検出できるようにしている。調べてみると「オプション」 と言うのはServerについての  とは「整合性ストリーム」と指定しないことも可能と言う事で、Windows 8.1の場合ReFS上の全てのファイルやフォルダーがディフォルトで「整合性ストリーム」になっている様である。

そうなるとデータを書き込む都度チェックサムを更新していたはずだ。その場合チェックサムを計算する対象が書き込むデータだけとは限らない。むしろすでにファイルシステムに存在するデータと合わせてチェックサムを計算しなければならない場合の方が多いのではないか。つまりRead-modify-writeが必要になる、と言うこと。またディスク上で離れている複数の場所にRead/Writeする必要があるかもしれない。この時キャッシュ等が利用できなくて都度ディスクから読み込むようだと、1回の書き込みにディスク何回転分もの時間がかかっていてもおかしくない。

ATTOで「Direct I/O」のチェックを入れる (これがディフォルト) とこのような動きになるのだろうか。

CDMもWindowsキャッシュの影響を受けないようにしているはずだが、もっとハードウエアに近いところにあるキャッシュ等の効き方がATTOとは微妙に違うのかもしれない。試しに「Direct I/O」のチェックを外してATTOで測ってみた。

この場合Windowsキャッシュが効いているはずなのでReadの数字は全く参考にならない。

ブロックサイズ512kB以上のWriteパフォーマンスは他の方法で測った数字とつじつまが合っているようだ。しかしブロックサイズ256kB以下のWriteパフォーマンスが単体ディスクよりも良くなっている理由は分からない。Write-backキャッシュは使っていないはずなので謎である。

Windows 8.1とServer 2012 R2の違い

ここまで調べてきて、ReFSの能書きでServer 2012 R2には当てはまるがWindows 8.1には当てはまらないものがあることが分かった。主要なものついて、それぞれの評価版で私が確認できた結果をまとめてみた。

項目	Windows 8.1	Windows Server 2012 R2
ReFSが使えるパーティションの種類(1)	双方向 および 3方向ミラー 記憶域スペース	起動ディスクを除く全て (記憶域スペースでないものも含む)
ディフォルトで整合性ストリームに設定されるもの(2)	ReFS上の全てのファイルとフォルダー	なし ReFS を使用しているミラーおよびパリティ記憶域スペース上のファイルとフォルダー
Data Integrity Scan のディフォルトスケジュール(3)	なし (スケジュールタスクはあるが 無効になっている(4))	4週間毎 土曜23時
備考	(1) コントロールパネルまたはサーバーマネージャーで設定する場合 (2) 個別に設定するには PowerShell の Set-FileIntegrity コマンドレットを使う (3) タスクスケジューラーの \Microsoft\Windows\Data Integrity Scan で変更できる (4) 動的に有効化されるかもしれない

これらはもう少し捕捉する必要があるだろう。

私の理解が正しければ、ReFSは回復性 (Resilience) のある記憶域スペースと組み合わせないと有用ではない。ReFSだけでは不整合を修復できないからである。一部のデータが壊れて不整合が検出された場合、復元性があればそれを利用して修復することができるが、復元性が無ければエラーを通知することしかできないはずだ。サーバーOSはこういった事情を理解できる専門家が扱うが、クライアントOSは必ずしもそうではないので、上のようなアレンジになったものと考えられる。

整合性ストリームは書き込まれる時にユーザーデータのチェックサムが記録されるが、それが役に立つのは読まれる時である。読まれたユーザーデータの一部が壊れているとチェックサムを使って不整合が検出される。ただし復元性のあるパーティション、例えば双方向ミラーの場合、読まれなかった方のコピーが壊れていても不整合は検出されないはずだ。この後、壊れていない方のコピーを保存しているディスクに障害が発生すると整合性のある正しいデータが失われ、再構築の際に不整合が検出されるが双方向ミラーではそれを修復することができない (3方向ミラーなら修復できる)。

Data Integrity Scanが私が期待している通りの処理をしているなら、実行すると全てのコピーの不整合を検出し、復元性を利用して修復してくれるはずである。つまりData Integrity Scanを行わないと、知らないうちに壊れてしまったデータが修復されない場合がある。このことを考えると、ReFS上の全てのファイルとフォルダーがディフォルトで整合性ストリームになるWindows 8.1で、Data Integrity Scanのスケジュールタスクが無効になっているのはバランスを欠くように思える。

「定期的なスクラブ処理でデータの検証と修復が行われる」と言うのはServer 2012 R2についての事で、Windows 8.1には当てはまらないのではないか。

Windows 8.1でReFSを使うならData Integrity Scanのスケジュールを有効にして実行タイミングを調整する必要があるだろう。なお「Data Integrity Scan for Crash Recovery」と言う名前のスケジュールタスクもあって、これはWindows 8.1でも有効になっている。しかしこれがどのような場合に何を行うのか不明だ。試しに手動実行してみたが、スクラブ処理を行っている様子はないのでData Integrity Scanの代わりにはならない。

上の表にも記載した通りData Integrity Scanのスケジュールはタスクスケジューラーの \Microsoft\Windows\Data Integrity Scan フォルダーにある (8.1とServer 2012 R2共通: 図はWindows 8.1)。

またData Integrity Scanの処理結果はイベントビューアーの \アプリケーションとサービスログ\Microsoft\Windows\DataIntegrityScan フォルダー内のログで確認できる (8.1とServer 2012 R2共通: 図はServer 2012 R2)。

なお処理対象を選んでData Integrity Scanを実行することはできないようだ。私が試したところ、約700GBのデータをスクラブするのに約3時間かかった。個々のファイルを識別して実行するので、サイズの小さいファイルが多数あるとデータ量の割に長い時間かかる。またCPU負荷はさほど高くない (概ね30%以下) が、スクラブ処理中のディスクに対するアクセスが遅くなる影響があった。

今回のまとめ

双方向ミラー記憶域スペースでReFSを使った場合、単体ディスクでNTFSを使った場合の約80%のSeq. Writeパフォーマンスが得られた。またSeq. Readパフォーマンスは単体ディスクとほとんど同じなので十分使い物になりそうである。

ベンチマークツールは時として使い物にならない数字を吐き出すことがある。ReFSのような新しい仕組みはATTOの想定外だったかもしれない。数字になりにくい場合があるかもしれないが、実際の使用方法に条件をできるだけ近づけて試した結果が一番役に立つはずだ。

実際、この記事を書く前すでにReFSの使用を開始している。それに伴い総量約700GBのデータをコピーしているが、特に遅いと感じたことはなかった。

Windows 8.1でReFSを使う場合、Data Integrity Scanが実行されるようタスクスケジューラーで調整する必要がある。ただし必ずしも定期的なスケジュールである必要は無いかもしれない。クライアント機の場合、利用者の都合に合わせて手動実行する方が好ましい場合もある。そうならばタスクは有効にし、定期的なスケジュールを無効にする必要がある。