このページの本文へ

前へ 1 2 次へ

Windows Info 第404回

開発者向けに性能が高い、Windowsの「開発ドライブ」を試す

2023年11月05日 10時00分更新

文● 塩田紳二 編集● ASCII

  • この記事をはてなブックマークに追加
  • 本文印刷

 現行のWindows 11 Ver.22H2では、「開発ドライブ(Dev Drive)」という機能が利用可能になっている。開発ドライブとは、ReFS(Resilient File System)を使う開発者向けのドライブである。Windows 11のビルド22621.2338以降、通常版であれば、9月に配布が開始されたOSビルド22621.2361(KB5030310)以降であれば利用できる。

開発ドライブ

Windows 11上で開発ドライブを作成するには、「設定」→「システム」→「ストレージ」→「記憶域の管理」→「ストレージの詳細設定」→「ディスクとボリューム」にある「開発ドライブを作成する」を使う

そもそも開発ドライブとは?

 開発ドライブは、ReFSを用いて、基本設定やセキュリティ設定を変更することで、性能を向上させる開発者向けの「ドライブ」である。ただし、性能向上のためには、Copy On Writeと呼ばれる機能を使い、ファイルを読み書きさせる必要がある。このため、通常のアプリをそのまま使っても性能向上は望めない。

 Microsoftが提供する.NETコンパイル用のMS-BuildツールなどがCopy On Writeに対応しているため、Visual Studioなどを使った開発利用では、20~40%程度の性能向上が認められるという。

 Copy On Writeは簡単に言えば、ファイルのコピーを見かけ上は終了させておき、書き込みがあったときだけ該当のブロックをコピーして書き換える方法だ。ファイルを実際にはコピーしないため、コピー操作自体は短い時間で終了する。そのためにReFSの「ブロッククローン」(https://learn.microsoft.com/ja-jp/windows-server/storage/refs/block-cloning)と呼ばれる機能を利用する。

 一般にファイルは、名称と記録位置などを記録してある「ディレクトリ」情報を使って管理されているが、Copy On Writeでのコピーは、このディレクトリ情報だけを作り、ファイルの実態はコピー元ファイルのブロックを参照する。ただし、Copy On Write用のファイルのブロックは参照カウントとともに他のファイルとブロックを共有していることが記録される。

 もし、コピーされたあとに、コピー先のファイルが書き換えられなかったときには、コピー元ファイルのすべてのブロックをコピーするための時間をほぼ省略できる。また、コピー元/コピー先のどちらで書き込みが起こっても、その該当ブロックをコピーして書き換えるだけでいいのでやはり短時間で終了する。

 問題は、Copy On Writeを使うためには、Windowsが用意するCopy On Write専用のAPIを使わねばならないことだ。たとえば、アプリケーションが自分でファイルを読み込んで、新規作成したファイルに書き込むという方法でコピーした場合には、Copy On Writeは有効にならない。

それではReFS(Resilient File System)とは?

 ReFS(Resilient File System、回復力のあるファイルシステム)は、Windows Server 2012に最初に搭載された新しいファイルシステムである。

 ReFSは、NTFSよりもファイルやボリュームの最大サイズが拡張されている。以下の表はReFSとNTFSの比較だ。ただし、NTFS、ReFSの双方に搭載されている機能や、Windows Serverでのみ有効な機能は入れていない。この表はマイクロソフトのReFSの解説ページ(https://learn.microsoft.com/ja-jp/windows-server/storage/refs/refs-overview)を元に筆者が作り直したものだ。

開発ドライブ

 ReFSはNTFSより高性能である反面、NTFSが持っている機能の一部に対応していない。最大の違いは、ReFSはWindowsの起動はできないことだ。このため、現時点ではNTFSの後継とは言いがたい。

 しかし、システムの起動が可能かどうかは、ファームウェアやブートローダー、そしてOSの問題であり、ReFS自体が持つ特性だけでは決まらない。つまり、これはマイクロソフトの政策的な決定であり、現時点ではReFSでシステム起動をさせたくないということなのだろう。

 リムーバブルメディアではReFSは利用できないとされているが、公式な表現としては“未サポート”状態であり、実際には利用可能である。ただし、昨年のWindows Updateのあと、リムーバブルメディア上のReFSがマウント不可能になったことがあった。サポートされるまでは、リムーバブルメディアでの利用は避けるべきだろう。

 また、ReFSは比較的頻繁にアップデートされる。後方互換性はリードオンリーで、旧形式のReFSは、新しいReFSではリードオンリーでのマウントのみが可能になる。ただし、Windowsをアップグレードする際にReFSのフォーマットに互換性がない場合にはドライブの自動アップグレードがなされる。

 基本的には、サーバーによる大規模ファイルシステムの構築を想定しているため、記憶域スペースを併用することで信頼性を向上できる。逆に言えば、ReFSは記憶域スペースでミラーリングやパリティなどを使わないと、信頼性としてはNTFSと大きく変わらない。

 ファイルのチェックサムを使った整合性チェックをするよう設定できるが、単体ドライブの場合はエラーがあったとしても、エラーが報告されて、ファイルがアクセスできなくなるだけである。記憶域スペースでミラーリングなどをしている場合には、他のドライブの情報を使いエラーファイルの修復を試みる。

 信頼性という点からいうと、NTFSは1993年から30年改良が続けられているが、ReFSは2012年からの11年だ。ソフトウェアとして、この時間の差は大きい。ReFSはこの先も利用範囲を拡大させながら、改良が続けられると考えられる。

 もう1つの特徴は、スパースVDL(Valid Data Length)と呼ばれる機能で、連続するゼロの領域をディスク上に割り当てないことが可能になり、大量のゼロを含むファイルを短時間で作成でき、ストレージ利用が効率的になる。

 特に容量固定の仮想ハードディスクファイル(VDL)の作成を短時間で終了できる。現在のReFSでは、クラスタ単位でVDLを持ち、クラスタ内がすべてゼロの場合にはファイル領域を確保しない。書き込みされたときに、初めてクラスタが確保される。すべてのブロックをコピーする必要がないことから、特に仮想マシンのスナップショットの作成を短時間で終了させる効果がある。

 最新のReFSのバージョンは3.10(Windows 11 Ver.22H2)であり、開発ドライブはこのバージョンを利用する。

前へ 1 2 次へ

カテゴリートップへ

この連載の記事

注目ニュース

ASCII倶楽部

プレミアムPC試用レポート

ピックアップ

ASCII.jp RSS2.0 配信中

ASCII.jpメール デジタルMac/iPodマガジン