Windows の次世代ファイル システム: ReFS

この記事では、前回に引き続きデータ ストレージを扱い、Windows 8 で導入される次世代ファイル システムについてお話ししたいと思います。NTFS は現在、一般的に使用されている中で最も先進的で機能に富み、広く普及したファイル システムとなっ ています。しかし Windows の完全な刷新を目標に掲げる Windows 8 では、過去の成功に甘んじることはしません。ファイル システムについても、新たに開発されたものを導入します。新しい ReFS (Resilient File System) は、基礎部分 に NTFS と同じ技術を使用することで重要な部分での互換性を確保しつつ、新しい世代のストレージ テクノロジやシナリオに合わせて設計および開発されています。過去のすべての新ファイル システム導入ケースと同様、Windows 8 の段階では、Windows Server 8 にのみ ReFS が組み込まれます。もちろん、アプリケーションのレベルでは、ReFS に保存されたデータにも NTFS のデータと同様にクライアントからアクセス可能です。さしあたり、現時点では PC 上のファイル システムとして NTFS が主要テクノロ ジであることを念頭にお読みください。

アーキテクチャに詳しく言及した今回の記事は、Storage and File System (ストレージ/ファイル システム) チーム所属の開発マネージャーである Surendra Verma が執筆していますが、他にも多くのメンバーが寄与している 点は他の機能と同様です。また、今回も FAQ セクションを設けています。
--Steven

追記: @buildwindows8 のフォローをお忘れなく。CES からの最新情報も発信しています。

---

このブログ記事では、Windows の新しいファイル システムについてお話ししたいと思います。ReFS と呼ばれるこのファイル システムは、Windows の多様な展開形態を視野に入れ、現在そして将来のユーザー要件に幅広く対応することを目指して、ゼロか ら設計されたものです。

ReFS の主な目標は次のとおりです。

• NTFS の機能のうち、広く使用されているものについては互換性を高い水準で維持し、システムの複雑性やフットプリント面でのコストに対して得られる価値の小さい機能は削減する。
• データの検証と自動修正を行う。データはさまざまな理由で破損することがあるため、検証を行い、可能であれば自動的に修正する必要がある。後述する "書き込み時のデータ欠落" の発生を防ぐため、インプレースでのメタデータ書き込みは行わない。
• 極端なスケールにも対応できるよう最適化する。すべての側面でスケーラブルな構造を採用する。特に、ディスク チェックのアルゴリズムが、ファイル システム全体の規模に対応できるとは考えないよう注意する。
• ファイル システムが決してオフラインにならないようにする。データ破損が起きた場合には、障害が発生した部分を隔離しつつ、ボリュームの残りの部分に対するアクセスは維持することを目指す。また、その間も、使用を続けつつ、可能な限り多くのデータをサルベ ージする。
• ReFS との連携を念頭に設計および開発された "記憶域" 機能との併用によって、完全なエンド ツー エンドの回復性を実現する。

ReFS の主要な機能は次のとおりです (一部の機能は "記憶域" 機能と密接に関連します)。

• チェックサムを使ったメタデータの整合性確保
• 整合性ストリームによる、オプションとしてのユーザー データの整合性確保
• 書き込み時割り当てトランザクション モデルによる信頼性の高いディスク更新 (コピー オン ライトとも呼ばれる)
• サイズの大きなボリューム、ファイル、およびディレクトリへの対応
• ストレージのプール化と仮想化によるファイル システムの作成と管理の簡略化
• データのストライピングによるパフォーマンス向上 (帯域幅は管理可能) と、フォールト トレランスのための冗長性確保
• 潜在的なディスク エラーを防ぐディスク スクラブ処理
• あらゆる場面でボリュームの可用性を最大限に確保する "サルベージ" によるデータ破損からの復元
• 複数のマシンを横断する共有ストレージ プールによるエラー許容と負荷分散

これに加えて、BitLocker による暗号化、アクセス制御リストによるセキュリティ、USN ジャーナル、変更通知、シンボリック リンク、接合ポイント、マウント ポイント、再解析ポイント、ボリューム スナップショット、ファイル ID、Oplock など、ReFS が NTFS から引き継いでいる機能およびセマンティクスがあります。

また、ReFS に保存されているデータには、現在の NTFS ボリュームにアクセスできるオペレーティング システムで使用されているクライアント上のファイル アクセス API であれば、もちろんアクセス可能です。

主なデザイン属性および機能

ReFS のデザイン属性は、私たちが掲げる目標と密接に関連するものとなっています。これからそれらの属性を紹介していきますが、その際、私たちがこれまで、最もフットプリントの小さなマシンから最も大規模なデータ センターまで、最も小さなストレージ フォーマッ トから最大規模の複数スピンドル フォーマットまで、ソリッドステート ストレージから最も大きなドライブやストレージ システムまで、何億ものデバイスで使用されるファイル システムの構築を行ってきたという背景を念頭に置いてください。しかも、Windows のファイル シ ステムは、最も多種多様なアプリケーションおよびシステム ソフトウェアによってアクセスされます。ReFS はこうした経験を基にした発展形です。まったくのゼロから始めるのではなく、刷新するのが理にかなっている部分では刷新を行い、NTFS を基にするべき部分ではそ のようにしてきました。何よりも、重要なファイル システムの提供にふさわしい、実用的な形での提供を目指しています。このような規模でのファイル システムの展開は、マイクロソフトにしか経験がないことです。

コードの再利用と互換性

ファイル システムの API は、互換性の確保が最も重要であり、かつ技術的に最も難しい領域です。ファイル システムのセマンティクスを実装するコードを書き直した場合、適切なレベルの互換性は望めません。アプリケーションのコード、呼び出しのタイミング、およ びハードウェアに強く依存する、さまざまな問題が生じることが予想されます。このため、ReFS を構築する際、Windows のファイル システムのセマンティクス実装にかかわるコードは再利用することにしました。このコードは、ファイル システムのインターフェイス (読み取 り、書き込み、開く、閉じる、変更の通知など) の実装、メモリ内のファイルおよびボリュームの状態の管理、ファイル データの同期およびメモリ キャッシュの管理を行うものです。この再利用により、NTFS から持ち越す機能において、高い水準の互換性を確保すること ができます。

この再利用部分の下で、NTFS 版のコード ベースでは、ファイルやディレクトリを表現するマスター ファイル テーブル (MFT) などのオンディスク構造を実装する、新しく設計されたエンジンを使用しています。ReFS では、この再利用コードを、まったく新しいエン ジンと組み合わせます。ReFS を裏打ちするイノベーションのうちのかなりの部分がこのエンジンに含まれています。図で表現すると次のようになります。

信頼性が高くスケーラブルなオンディスク構造

オンディスク構造とその操作は、オンディスク ストレージ エンジンが処理します。ここで見られるのは一般的なキー/値型のインターフェイスで、上部レイヤーはこれを利用してファイル、ディレクトリなどを実装します。ストレージ エンジン自体の実装には、B+ Tree (英語) のみが使用されます。実際のところ、B+ Tree は、ディスク上のすべての情報を表現する、唯一の共通オ ンディスク構造として使用されています。ツリーは他のツリーに埋め込むことができます (子ツリーのルートが親ツリーの行の中に格納されます)。ディスク上のツリーは、非常に大きな多階層のものにすることも、少数のキーのみを持ち別の構造に埋め込まれた非常にコンパク トなものにすることも可能です。これによって、ファイル システムのあらゆる面で、上下両方向に非常に柔軟なスケーラビリティが実現します。構造が 1 種類であることでシステムが大幅に単純化され、コードの削減にもつながります。新しいエンジンのインターフェイスには、 キー/値ペアの列挙可能なセットである "テーブル" という概念が含まれます。ほとんどのテーブルは固有の ID (オブジェクト ID) を持ち、この ID によって参照することができます。また、システム内のテーブルすべてをインデックスする、専用のオブジェクト テーブル があります。

では、ファイル システムの一般的な概念が、テーブルを使ってどのように構築されるか見ていきましょう。

ファイル構造

上の図にあるとおり、ディレクトリはテーブルとして表現されます。テーブルは B+ Tree を使って実装されるため、ディレクトリは効率的にスケール可能であり、非常に大きなサイズとなります。ファイルは親ディレクトリの行の中に埋め込まれたテーブルとして実装されま す。親ディレクトリの行自体もテーブルとして表現されます (上の図の "ファイル メタデータ")。"ファイル メタデータ" テーブルの各行は、さまざまなファイル属性を表します。ファイル データのエクステントの位置は、埋め込まれたストリーム テーブルで表現されます。ス トリーム テーブルは、オフセットのマッピング情報 (およびオプションとしてチェックサム) のテーブルです。つまり、NTFS に見られるような制約はなく、非常に大きなファイルやディレクトリでも、パフォーマンスに影響することはありません。

予想されるとおり、ACL (アクセス制御リスト) など、ファイル システム内の他のグローバル構造は、オブジェクト テーブル内にルートを置くテーブルとして表現されます。

ディスク領域の割り当ては、階層的なアロケーターによって管理されます。アロケーターは、空き領域の範囲のテーブルによって空き領域を管理します。スケーラビリティのため、アロケーターのテーブルには、大、中、小の 3 種類があります。それぞれ管理する領域の大 きさが異なり、たとえば "中" のアロケーターは、"大" のアロケーターから割り当てられた中規模の領域を管理します。これによって、ディスク割り当てアルゴリズムは非常にスケーラブルになり、関連するメタデータを自然に配置することができるため、パフォーマンスが向上 します。これらのアロケーターのルートや、オブジェクト テーブルのルートは、ディスク上の既知の場所からアクセス可能です。一部のテーブルはプライベートなアロケーターを持っており、これによって競合が減り、割り当てのローカリティが向上します。

グローバルなシステム メタデータのほかに、オブジェクト テーブル内のエントリはディレクトリを参照します。これは、ファイルがディレクトリに埋め込まれているためです。

信頼性の高いディスク更新戦略

ディスクを更新する際の信頼性と効率性を確保することは、ファイル システム設計の上で最も重要かつ困難な点の一つです。私たちは時間をかけてさまざまなアプローチを検討しました。検討の結果却下したものの一つが、ログ構造ファイル システムです。このアプ ローチは、Windows が必要とするような多目的なファイル システムには適しません。NTFS は、トランザクションのジャーナルによってディスク上の整合性を確保します。このアプローチでは、ディスク上でインプレースでメタデータを更新し、ジャーナルを併用することによって 変更をトラッキングして、エラーが起きた場合や電源切れからの復旧の際にロールバックに使用します。このアプローチのメリットの一つは、メタデータのレイアウトをインプレースで保持することで、これによって読み取りパフォーマンスが向上するケースがあります。ジャーナル方式 の主なデメリットは、書き込みがランダム化される場合があること、そしてより重要な点として、書き込み中に電源が失われた場合、ディスク更新処理によって、以前に書き込んだメタデータが破損する可能性があることです。これを "書き込み時のデータ欠落" と呼びます。

信頼性を最大限に高め、書き込み時のデータ欠落を防ぐため、私たちは書き込み時割り当てモデルを採用しました。このアプローチでは、メタデータをインプレースで更新することはなく、アトミックな方法で別の場所に書き込みます。これはいくつかの点で、ディスク上の 構造を更新する際に信頼性を確保するための、かなり古くからある技術である "シャドウ ページング" にならったものです。トランザクションは、この書き込み時割り当て式のアプローチを基盤として構築されます。ReFS の上部レイヤーは NTFS から派生したも のであるため、新しいトランザクション モデルでは、多くのリリースを経てテストされ安定化されてきた既存のエラー回復ロジックを、シームレスに活用することができます。

ReFS のメタデータ割り当て方法では、関連するパーツ (たとえばストリーム割り当て、ファイル属性、ファイル名、ディレクトリ ページなど) について、書き込みをより大きな少数の I/O にまとめることができ、回転式のメディアでもフラッシュ メモリでも優れたパフォ ーマンスを発揮します。同時に、読み取り時の連続性も一定の範囲で確保されます。階層型の割り当て方式はこの点で重要な役割を果たします。

私たちは、システムに極端な負荷をかけた状態で電源を切断し、その後システムを再度オンにしてすべての構造が正常な状態に保たれているか検査するという方法で、入念にテストを行っています。このテストが、最終的な成功の度合を測るものとなります。現時点 で ReFS は、マイクロソフトのファイル システムとして、かつてないレベルの信頼性を達成しています。これは業界をリードする水準であり、設計上の主要な目標を達成できたものと考えています。

ディスク破損からの復元性

前述のとおり、設計上の主な目標の一つに、破損の検出と修正という点があります。これはデータの整合性を確保するだけでなく、システムの可用性とオンラインでの操作性を改善することにもつながります。このため、ReFS のすべてのメタデータは、B+ Tree の ページのレベルでチェックサムの検査を受け、チェックサムはページそのものとは別個に保存されます。これによって、書き込みの欠落やミス、"ビット腐敗" (メディア上のデータの劣化) を含め、あらゆる形のディスク破損を検出することができます。これに加えて 、ファイルの内容についてもチェックサムの検査を行うオプションも用意しています。"整合性ストリーム" と呼ばれるこのオプションを有効にした場合、ReFS は、ファイルの変更を常に元の場所とは異なる位置に書き込みます。この書き込み時割り当て方式の技術により 、新しいデータの書き込みによって既存のデータが失われる心配はなくなります。チェックサムの更新はデータの書き込みと共にアトミックに行われるため、書き込み中に電源が失われても、ファイルの検証可能なバージョンが常に確保され、破損を確実に検出することができ ます。

数週間前に、このブログで "記憶域" についての記事を公開しました。ReFS と "記憶域" 機能は、完全なストレージ システム を構成する 2 つのコンポーネントとして、相補的に設計されています。"記憶域" 機能は NTFS でも (つまりクライアント PC でも) 提供されますが、これはそれによって得られる大きなメリットを意識してのことです。アーキテクチャのレイヤー化によって、クライアン ト側でのこのアプローチをサポートしつつ、ReFS の調整を進め、最終的にはクライアントとサーバーの両方で ReFS を利用できるようにすることを目指します。

パフォーマンスの向上に加え、"記憶域" 機能では、データのコピーを複数のディスク上に維持することで、部分的または完全なディスク障害からデータを保護します。読み取りエラーが発生した場合は別のコピーから読み取りを行うことができ、書き込みエラー (およ び読み書き時の完全なメディア喪失) が起きた場合は、データを透過的に再割り当てすることができます。多くのエラーは、メディアが原因ではなく、データの破損や書き込みの欠落およびミスによって起こります。

これらは、まさに ReFS がチェックサムを使って検出できる種類のエラーです。ReFS は、こういったエラーを検出すると、"記憶域" 機能と連動して利用可能なすべてのコピーを読み取り、チェックサム検証に基づいて正しいものを選びます。その後、正常なコピー に基づいて不良コピーを修正するよう、"記憶域" に連絡します。これらの処理は、いずれもアプリケーションには意識されることなく行われます。ミラー化された記憶域を使用していない場合、ReFS は破損を自動修正することはできません。この場合、破損が検出され たことを示すイベントをログし、ファイル データの場合は読み取りを失敗させます。これによるメタデータへの影響については後ほど詳しく触れたいと思います。

チェックサム (64 ビット) は ReFS メタデータでは常時オンになっており、ボリュームがミラー化された記憶域上でホストされている場合は自動修正も常時オンになっています。整合性ストリーム (下を参照) はすべて同様に保護されます。これによって、エンド ツー エンドで高い整合性を確保するソリューションが実現され、比較的信頼性の低いストレージも信頼性の高い状態で使用することができます。

整合性ストリーム

整合性ストリームは、あらゆる形のデータ破損からファイルを保護します。この機能は多くのシナリオで有益ですが、一部には適さないケースもあります。たとえば、アプリケーションによっては、ファイル ストレージを独自に注意深く管理し、ディスク上に決まったレイアウト でファイルを展開する必要があります。整合性ストリームではファイルの内容を変更するたびにブロックの再割り当てを行うため、こういったアプリケーションがファイルのレイアウトを予測することが難しくなります。データベース システムなどはその好例と言えるでしょう。こういった アプリケーションはまた、ファイルの内容のチェックサムを独自に保有し、"記憶域" API と直接やり取りしてデータの検証と修正を行うことができるケースが一般的です。

特定のファイル レイアウトが必要な場合のために、この設定をさまざまな精度で制御するためのメカニズムと API を用意しています。

最も基本的なレベルでは、整合性はファイルの属性 (FILE_ATTRIBUTE_INTEGRITY_STREAM) です。また、ディレクトリの属性でもあります。ディレクトリ内にある場合、属性はそのディレクトリ内に作成されたすべてのファイルおよびディレクトリに継承さ れます。"format" コマンドを使用すると、ボリュームのフォーマット時に、ルート ディレクトリに対してこの指定を行うことができます。ルートでこの設定を行うことで、ボリューム上のすべてのファイルおよびディレクトリで、既定の属性に設定することができます。以下に例を 示します。

 D:\>format /fs:refs /q /i:enable <volume>

D:\>format /fs:refs /q /i:disable <volume>

既定では、/i スイッチを指定しなかった場合、ボリュームがミラー スペース上にあるかどうかによってシステムの動作が決まります。ミラー スペース上ではメリットがコストを大きく上回る可能性が高いため、整合性がオンになります。アプリケーションがプログラム的にこの
設定を上書きすることはいつでも可能です。

"ビット腐敗" への対策

既に触れたように、ReFS と "記憶域" 機能の組み合わせによって、ディスク破損やストレージ エラーの際も、高いレベルのデータ復元性を確保することができます。より検出や対応が難しいのは、"ビット腐敗" によって起きるデータ損失です。これは、ディスクの
一部が経時的に破損していき、読み取りが頻繁に行われないためにそのことが検出されない事態を指します。読み取りが行われ、破損が検出されるころには、代替コピーも破損していたり、他のエラーが原因で失われている可能性があります。

ビット腐敗に対応するため、ミラー化された記憶域上の ReFS ボリュームで、すべてのメタデータと整合性ストリーム データに対して、定期的にスクラブ処理を行うシステム タスクを追加しました。スクラブ処理では、冗長コピーをすべて読み取り、ReFS チェックサ
ムを使ってデータを検証します。チェックサムに不一致があった場合、不良コピーは正常なコピーを使って修正されます。

ファイル属性 FILE_ATTRIBUTE_NO_SCRUB_DATA は、そのファイルをスクラブ処理の対象に含めないことを示します。この属性は、整合性情報を独自に保有するアプリケーションで、アプリケーションの開発者がファイルのスクラブ処理のタイミングと方法を
より細かく制御したいと考える場合に便利です。

コマンドライン ツール Integrity.exe は、整合性およびスクラブ処理についてのポリシーを管理する強力な手段となります。

対策がすべて失敗した場合に: ボリュームの可用性の継続

多くのユーザーは、ミラー化された記憶域と組み合わせて ReFS を使用することが見込まれます。この場合、破損は自動的に、ユーザーに意識されることなく修正されます。しかし、まれにではありますが、ミラー スペース上のボリュームも破損する可能性があります
。たとえば、不良なシステム メモリによってデータが破損し、それがディスクに侵入すれば、冗長コピーもすべて破損します。加えて、ユーザーが ReFS ボリュームをホストするのに、ミラー化された記憶域を使用しない可能性もあります。

このようなケースでボリュームの破損が起きた場合、ReFS は "サルベージ" を行います。サルベージでは、使用中のボリュームの名前空間から破損データを取り除きます。この機能の趣旨は、修復不能の破損によって正常なデータの可用性に悪影響が出るのを
防ぐことにあります。たとえば、ディレクトリ内の 1 つのファイルが破損し、自動修復が不可能になった場合、ReFS はそのファイルをファイル システムの名前空間から取り除き、ボリュームの残りの部分をサルベージします。この処理は通常 1 秒未満で完了します。

通常、ファイル システムは破損したファイルを開くことも削除することもできないため、管理者は手を打つことができません。しかし ReFS が破損データをサルベージすることで、管理者は、ファイル システムをオフラインにすることなく、そのファイルをバックアップから復元
したり、アプリケーションに再度作成させることができます。この重要なイノベーションにより、オフラインでディスク チェックや修正を行う高価なツールを実行する必要もなくなり、破損によって長時間のオフライン状態が発生する心配をすることなく、非常に大きなデータ ボリュ
ームを展開することができます。

Windows 記憶域スタックへのスムーズな組み込み

設計においては最大限の柔軟性と互換性を実現する必要がありました。周辺の他のレイヤーとの互換性を最大限に保つため、ReFS は通常のファイル システムと変わりなく記憶域スタックにプラグインできるようになっています。たとえば、BitLocker による暗
号化、アクセス制御リストによるセキュリティ、USN ジャーナル、変更通知、シンボリック リンク、接合ポイント、マウント ポイント、再解析ポイント、ボリューム スナップショット、ファイル ID、Oplock などを、シームレスに使用することができます。ほとんどのファイル シ
ステム フィルターは、最低限の調整、あるいはまったく調整なしで、シームレスに ReFS を扱うことができる見込みです。このことはテスティングによって裏付けられており、たとえば既存のウィルス対策ソリューションである Forefront が機能することを検証できまし
た。

NTFS の物理フォーマットに依存する一部のフィルターの場合は、より大幅な調整が必要です。マイクロソフトでは、ファイル システムに対しては、サードパーティのウィルス対策、バックアップなどのソフトウェアとの連動をテストする、広範な互換性プログラムを実施して
います。ReFS についても同様のテストを行っており、互換性に問題が見つかった場合は主要パートナーと協力して対応していきます。これは、ReFS に限らず、過去にも行ってきたことです。

柔軟性についてもう一つ触れておきたいのは、ReFS と "記憶域" 機能は、組み合わせて使用すると効果的であるものの、それぞれ独立して機能するよう設計されているという点です。これによって、両コンポーネントが互いに不要な制約を与えることなく、展開
時の柔軟性が最大限に確保されます。別の言い方をすれば、完全なストレージ ソリューションを選択するにあたって、信頼性とパフォーマンスのトレードオフが可能ということになります。たとえば、パートナー企業が提供するストレージを基盤として ReFS を展開すること
もできます。

"記憶域" 機能により、ストレージ プールを複数のマシンで共有することができ、仮想ディスクをマシン間で相互に移動させることができるため、エラーに対するさらなる復元性が実現します。ReFS はこのことを最大限に活かせるような設計になっています。

実用

ReFS は、NTFS のために 20 年以上にわたって開発され、綿密に組み合わせられた何万もの膨大なテストを経ています。これらのテストは、システムへの負荷、電源切断などの障害、スケーラビリティ、パフォーマンスなどの面で、実際の展開で予想される要
件をシミュレートし、上回る内容となっています。ReFS は、管理された環境で実際に展開してテストする準備が整った状態と言えるでしょう。ただし大規模なファイル システムの最初のバージョンであるため、ある程度の注意は必要です。Windows 8 の ReFS
は "ベータ版" と呼ばれる状態では提供しません。Windows 8 がベータ段階を抜ければ、ReFS は、データの信頼性よりも重要なものはないという点を強調しつつ、実稼働に耐えるリリースとして提供されます。システムの他の要素と異なり、初期の展開とテスティ
ングについては保守的なアプローチが必須と言えるでしょう。

これを念頭に、私たちは ReFS を段階的に進化させていきます。まずは Windows Server 用のストレージ システムとして、続いてクライアント向けのストレージとして、そして最終的にはブート ボリュームとして実装します。これは、過去に新しいファイル
システムに対してとってきたアプローチと同様です。

まずは ReFS をファイル サーバーとして実行することを主眼としたテストを行っていきます。ユーザーの皆さんにも、ファイル サーバーとして、特にミラー化された記憶域上でメリットを実感していただけるものと思います。また、ストレージ関連のパートナーと協力して、
ストレージ ソリューションへの組み込みにも取り組んでいきます。

まとめ

ReFS は、"記憶域" 機能と共に、次の 10 年またはそれ以上にわたって、Windows のストレージの礎石となるものです。これはストレージ技術の水準を大きく前進させるものと考えています。"記憶域" 機能と ReFS は、今後のさらなるイノベーション
を視野に入れて設計されています。ReFS が、大規模に展開されるファイル システムとして、次世代を担うものとなることを期待しています。

-- Surendra

FAQ:

Q) ReFS という名前の由来は何ですか?

ReFS は "Resilient File System" (復元性のあるファイル システム) を表します。ReFS にはさまざまな側面で改善点が盛り込まれていますが、復元性はその中でも特に重要な要素の一つです。

Q) ReFS の容量面での上限は?

次の表に、オンディスク フォーマットとしての容量の上限を示します。他の面で実用上の制約が生じる可能性はあります。たとえばシステム構成 (メモリの量など)、各種システム コンポーネントによって生じる制約、データ セットへのデータ読み込みにかかる時間、
バックアップに要する時間などが考えられます。

Q) NTFS と ReFS の間でデータを変換することはできますか?

Windows 8 では、インプレースでデータを変換する方法はありません。データをコピーすることは可能です。これは、今日見られるデータ セットの大きさと、この変換処理をインプレースで行うことの実用性の低さ、加えて変換前後で見込まれるアーキテクチャ上のア
プローチの変化を考慮した、設計上の意図的な決定です。

Windows Server 8 で ReFS から起動することはできますか?

いいえ。実装もサポートも行われません。

Q) リムーバブル メディアやリムーバブル ドライブで ReFS を使用することはできますか?

いいえ。実装もサポートも行われません。

Q) NTFS のセマンティクスおよび機能のうち、ReFS ではサポートされないものはどれですか?

ReFS でサポートしないことになった NTFS の機能は、名前付きストリーム、オブジェクト ID、短い名前、圧縮、ファイル レベルの暗号化 (EFS)、ユーザー データ トランザクション、スパース、ハード リンク、拡張属性、およびクォータです。

Q) パリティ スペースと ReFS の関係はどのようになりますか?

"記憶域" 機能が提供する障害に対する復元性のオプションでは ReFS がサポートされます。Windows Server 8 では自動データ修正はミラー スペースについてのみ実装されます。

Q) クラスタリングはサポートされますか?

個別のボリュームがマシン間でフェールオーバーするフェールオーバー クラスタリングがサポートされます。このほか、クラスター内の共有ストレージ プールがサポートされます。

Q) RAID はどうでしょう? ReFS のストライピング、ミラーリング、あるいはその他の形式の RAID の機能はどのように使用しますか? ReFS ではたとえば、ビデオに必要な読み取り性能は提供されますか?

ReFS は "記憶域" のデータ冗長性機能を使用します。これにはストライピングされたミラーとパリティが含まれます。ReFS の読み取り性能は、関連コードの多くを共有する NTFS に近いものとなることが見込まれます。データのストリーミングでは非常に優れ
た性能を発揮するはずです。

Q) ReFS に、重複除去、DRAM とストレージの間の 2 次キャッシュ、書き込み可能スナップショットの機能がないのはなぜですか?

ReFS 自体は重複除去の機能を提供しません。NTFS と同様、他の重複除去製品を ReFS にプラグインすることが可能です。これは、従来どおりのプラグ可能なファイル システム アーキテクチャを採用していることによる、付帯的なメリットと言えます。

ReFS では明示的な実装は行われていませんが、ユーザーはサードパーティのソリューションを使って 2 次キャッシュを実現することができます。

ReFS は、VSS と連動して、Windows 環境における NTFS と整合性のある形でスナップショット機能を提供します。現時点では、書き込み可能スナップショットや、64 TB を超える大きさのスナップショットはサポートされません。

Comments

• Anonymous
  January 22, 2012
  新しいファイルシステム、なるほどですね。一日でも早く、普及していくといいなと思います。今後もまた、いろいろと紹介して下さい。翻訳も米国版出たら、なるべく早めにお願いいたしますね。楽しみにしております。
• Anonymous
  January 26, 2012
  次の記事が2つ、米国本社のブログにはあります。お忙しいのかもしれませんが、次の翻訳をおねがいいたします。
• Anonymous
  February 09, 2012
  ハード リンクがなくなってるとsubversionあたりで困りそうだなぁ
• Anonymous
  April 06, 2012
  ＷinNT3.5 で NTFS にであった時の感動をまた味わえるのでしょう。FAT -> (FAT32 ->) NTFS -> ReFS 長い道のりですが期待しています。要望：開発言語に FS 操作系の API や関数をもっと増やしてください。特に LINK 関係。
• Anonymous
  August 22, 2012
  役立ちました。 ありがとうございます。翻訳されていたのでとても助かりました。