« PSUを交換したらメモリーの問題も解決した | トップページ | SATAアダプターを交換した »

2014年6月22日 (日)

ReFSを使う

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

Atto_refs

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のパーティションにコピーしてみた。

Copy_to_refs_98

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

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

Cdm_refs

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

 

ReFSのチェックサム

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

Getfileintegrity

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

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

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

Atto_refs_no_direct_1

この場合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)。

Client_datainteg_task_trigger

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

Server_datainteg_task_event

なお処理対象を選んで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が実行されるようタスクスケジューラーで調整する必要がある。ただし必ずしも定期的なスケジュールである必要は無いかもしれない。クライアント機の場合、利用者の都合に合わせて手動実行する方が好ましい場合もある。そうならばタスクは有効にし、定期的なスケジュールを無効にする必要がある。

|

« PSUを交換したらメモリーの問題も解決した | トップページ | SATAアダプターを交換した »

IT」カテゴリの記事

パソコン・インターネット」カテゴリの記事

趣味」カテゴリの記事

コメント

2012 R2の整合性ストリームの規定値を一括で「なし」と書いてますけど、実際に確かめた上で言うとformat /?のヘルプやMSの前情報通りミラー記憶域とパリティ記憶域(かつダイナミックディスクにしていないもの)で有効それ以外で無効です

投稿: | 2014年9月26日 (金) 23時42分

コメントありがとうございます。テスト環境を壊してしまっていたので、再構築して調べ直しました。
ご指摘の通り、サーバー2012 R2ではミラーとパリティ記憶域スペースではディフォルトで整合性ストリームに設定される様です。
記事作成時点では、本文に記載のとおり「評価版で私が確認できた結果」整合性ストリームが設定されるものは無かった、これには自信があります。
しかしそうなるとミラーもパリティも確認していなかった、と言うことになりますね・・・
記事の趣旨からして分かってそうしていることはあり得ないので、よほど何か勘違いしていた様です。お恥ずかしい限り。
記事を訂正しておきました。これもコメントをいただいたおかげです。
重ねて御礼申し上げます。

投稿: エンジニア | 2014年9月27日 (土) 12時24分

現状、Windows10でReFSを使用可能にすると、実際にReFSを使って無くてもイベントビューアが使えなくなる現象が発生するようです

投稿: | 2015年9月 9日 (水) 08時48分

名無し さん、
それって ↓ このことですか?
http://www.google.co.jp/search?hl=ja&q=Windows10+ReFS+%E3%82%A4%E3%83%99%E3%83%B3%E3%83%88%E3%83%93%E3%83%A5%E3%83%BC%E3%82%A2&lr=lang_ja
私は現在 Windows 10 にアップグレード済みで、ReFS を使い続けていますが幸いご指摘の現象に遭遇しなくて済んでいます。
私の場合特に「ReFSを使用可能にする」操作をした記憶は無いので、もしかすると ↓ ここにあるように、
http://akiba-pc.watch.impress.co.jp/docs/sp/20150501_700313.html
レジストリを編集して「記憶域スペース (Storage Space)」以外に ReFS を作ろうとした場合の問題なのかもしれませんね。

投稿: エンジニア | 2015年9月 9日 (水) 17時09分

新規インストール直後、レジストリを変更し再起動した時点で発生するんですよね
実際にReFS記憶域を作成すればエラーが出ないのかも知れませんが…
使用保証されていない機能ですから「こんなものか」と思っています

投稿: | 2015年9月10日 (木) 21時13分

Technet に「Windows 8.1 の mirrored Storage Spaces で ReFS が使える」ってアナウンスがあります。
http://technet.microsoft.com/en-us/library/hh831724.aspx#BKMK_ReFSclient
なのでこの使い方は正式な仕様で、Windows 10 にも引き継がれている、と言う事らしいです。
レジストリを編集して非記憶域スペースで使うのは「使用保証されていない」のみならず、おそらく「仕様外」なのでしょうね。

投稿: エンジニア | 2015年9月10日 (木) 22時42分

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/543745/59858135

この記事へのトラックバック一覧です: ReFSを使う:

« PSUを交換したらメモリーの問題も解決した | トップページ | SATAアダプターを交換した »