共用方式為

大容量ディスクとセクター サイズ拡大に対応する Windows 8

  • 發行項

ファイル システムは、OS が提供するサービスの中でも最も基本的なものの 1 つと言えます。そして Windows は、広く普及している OS の中でも、最も進んだファイル システムの 1 つを持つ OS です。Windows 7 では、信頼性、管理性、堅牢性の面で大幅な改良 (たとえば時代遅れとなっていた "デフラグ" の完全な自動化など) を行いました。Windows 8 ではこれに加えてスケーラビリティや容量に焦点を当てた改良を行っています。今回の記事は、Storage & Files Systems (ストレージ/ファイル システム) チーム所属のプログラム管理者、Bryan Matthew が執筆しました。
--Steven

ユーザーが保管するデジタル コレクションの規模は加速度的に拡大し続けています。高解像度のデジカメ写真、高画質のホーム ビデオ、大規模な音楽ファイルのコレクションなどがこの流れを強く後押ししています。ハード ディスク メーカーはこの課題に応えて非常に容量の大きなハード ディスク ドライブを供給しており、IDC の最近の市場調査レポートによれば、単一ハード ディスクの容量の上限は 2015 年までに 8 TB まで増えるものと推定されています。

容量は 2010 年には 2 TB、2011 年には 3 TB となり、その後、徐々に増加し続け、2015 年に 7 TB (予想値) に達している

単一ディスク ドライブの容量上限の推移
(出典: IDC 調査 # 228266「Worldwide Hard Disk Drive 2011–2015 Forecast: Transformational Times
(ハード ディスク ドライブにおける 2011 ～ 2015 年のグローバル予想: 転換期の様相)」、2011 年 5 月)

このブログ記事では、ユーザーがこのような超大容量ドライブをより効率的かつ完全に活用できるよう、業界パートナー各社の製品と歩調を合わせて Windows 8 がたどってきた進化の道のりをご紹介したいと思います。

超大容量のハード ディスク ドライブにまつわるさまざまな課題

まず前提として、ここでは 1 ドライブあたり 2.2 TB を超えるサイズのドライブを "超大容量" と定義しましょう。現行の Windows では、アーキテクチャ上のいくつかの制約により、一部のシナリオでこういったドライブの扱いがややトリッキーなものとなります。

ハード ディスク ベンダー各社が超大容量ドライブの提供を可能にするイノベーションを進める中、集中的な取り組みを要する 2 つの課題がありました。

  • ディスクを完全に活用するため、利用可能な容量すべてをアドレス可能にすること
  • セクター サイズを 4K に拡大して物理ディスクの管理効率向上を目指す、ハード ディスク ドライブ ベンダーの取り組みをサポートすること

では、この 2 つの課題について詳しく見ていきましょう。

利用可能な容量全体のアドレス

超大容量ディスクで利用可能な容量をすべてアドレス指定するという課題を十分に理解するには、次のコンセプトについて詳しく検討する必要があります。

  • アドレス方式
  • ディスクのパーティション構成
  • PC のファーム ウェア実装 (BIOS か UEFI か)


アドレス方式

当初ディスクのアドレスに使用されていたのは CHS (シリンダー ヘッド セクター) 方式でした。この方式では、ディスクのシリンダー、ヘッド、およびセクターを指定することによってディスク上のデータ ブロックの場所を特定します。2001 年に 160 GB のディスクが登場したときのことはまだ覚えています (筆者は中学生でした)。これによって CHS アドレス方式は限界 (約 137 GB) を迎え、より大容量のディスクに対応するためにシステムの再設計が必要となりました。[編注: ちなみに私が最初に使ったハード ドライブは 5 MB で、タワー PC くらいの大きさでした。--Steven]

新しいアドレス方式は Logical Block Addressing (LBA) と呼ばれ、個別的な座標によってセクターを指定する代わりに、セクター番号 (論理ブロック アドレス) を使ってディスク上のデータ ブロックを参照するものでした。Windows でも、この新しいメカニズムを活用してハード ディスク ドライブの容量のすべてをアドレス指定できるよう、システムの更新が行われました。LBA では各セクターが事前にサイズを定義されており (ごく最近までは 1 セクターあたり 512 バイト)、各セクターのアドレスは、セクター 0 からセクター n まで単調に増加する値で表現されます。数式で表すと次のとおりです。

n = (総容量 (バイト))/(セクター サイズ (バイト))

ディスクのパーティション構成

LBA アドレス方式ではアクセスできるディスクの容量が理論上は無制限となりますが、実際には "n" の最大値は使用されるパーティション構成によって制約されます。

ディスクのパーティションという概念は 1980 年代前半から見られます。当時のシステム開発者たちによってディスクを複数の "パーティション" に分けて扱うことの必要性が見いだされ、得られたパーティションをファイル システムによってフォーマットし、データの保存に使うという方法が採用されました。マスター ブート レコード (MBR) パーティション テーブルという概念が発明されたのもこの時期で、これは最大 32 ビットの情報でディスクの最大容量を表すものでした。単純な計算からわかるように、32 ビットで表現できるアドレス可能バイト数の上限は 232、つまり 2.2 TB となります。1980 年代には、この上限も現実的に理にかなったものと思われました。当時コンシューマー向けに流通していたディスクで最も大きなものがなんと 5 MB、価格は 1,500 ドルを優に超えていたことを考えれば、当然と言えます。

1990 年代後半には既に、2.2 TB の上限を超えるアドレスの必要性が (その他の要件と共に) 認識されていました。これを受けていくつかの企業がコラボレーションを行い、Unified Extensible Firmware Interface (UEFI) 規格の一部として、GUID パーティション テーブル (GPT) と呼ばれるスケーラブルなパーティション構成を開発しました。GPT ではディスクの最大容量を表現するために最大 64 ビットの情報を使用することができ、これによって理論上の上限値は 9.4 ゼタバイト (1 ZB = 1,000,000,000,000,000,000,000 バイト) となります。

64 ビット版 Windows Vista 以降、Windows は GPT によってパーティションが行われたハード ディスク ドライブからのブートに対応していますが、これには重要な要件が 1 つあり、システムのファームウェアが UEFI でなければなりません。UEFI についてはこのブログでもご紹介しましたので、Windows 8 PC の新しい機能として利用できることはもうご存知かと思います。そこで問題になるのはファームウェアです。

PC のファーム ウェア実装 (BIOS か UEFI か)

オペレーティング システム (Windows) に制御が渡されるまでの間に、基本的なハードウェアの初期化をはじめとするさまざまな処理を行うのが、PC ベンダーがシステムに組み込むファームウェアです。ファームウェア実装としては、歴史ある BIOS (基本入出力システム) が、PC が登場した 1980 年ごろから長年使用され続けています。その後の数十年において PC が遂げてきた大幅な進化を受け、BIOS を置き換えるものとして開発されたのが UEFI 規格です。UEFI 実装は 1990 年代後半から登場しています。UEFI は、GUID パーティション テーブル (GPT) を使って超大容量ドライブに対応できるよう、基本から設計されています。一部の BIOS 実装では、延命措置として代替的な対応策 (MBR と GPT を合わせたハイブリッドなパーティション構成など) を採用して大容量ドライブへの対応を試みていますが、こういったメカニズムは脆弱なものであることも多く、データが危険にさらされる可能性があります。このため Windows では、ブート ディスクで GPT 構成を使用する際は近代的な UEFI ファームウェアを組み合わせることを、一貫して要件に設定しています。

Windows 8 以降では、OS に追加されたさまざまな新機能で UEFI が必須となります。UEFI ファームウェア、GPT パーティション、そして LBA の組み合わせにより、Windows は超大容量ディスクを容易に扱うことができます。

パートナー各社は現在、Windows 8 で採用された革新的な機能やシナリオ (セキュア ブート、ドライブの暗号化、高速起動など) を可能にする、UEFI を使用した Windows 8 ベースのシステムの提供に向けて努力を続けています。Windows 8 がリリースされるころには、新しいシステムでは 3 TB 以上の巨大なディスクに Windows 8 をインストールし、そこからブートできるようになっているでしょう。次の画像はそのプレビューです。

空き領域 2.71 TB/2.72 TB の C ドライブが表示されている

UEFI システムで 3 TB SATA ドライブから Windows 8 をブートしたようす

4 KB へのセクター サイズ拡大

すべてのハード ディスク ドライブには、エラー訂正を行うための情報とロジックがなんらかの形で組み込まれています。これによって、ディスク プラッターからデータを読み取る際の SN 比 (SNR: 信号雑音比) を、ハード ディスク ドライブ ベンダーが自動的に処理することができます。ディスク容量の増大に伴い、ディスク上の各ビットの密集の度合も増し、読み取り時の SNR が低下します。SNR の低下に対応するため、ディスクの各セクターにより多くの ECC (エラー修正コード) を格納して、セクター読み取り時のエラー対応を支援する必要があります。この傾向が進んだ結果、近代的なディスクでは、現行の ECC 格納方式では容量が効率的に使用されているとは言えない状態になっています。つまり、現行のセクター サイズである 512 バイトの中で ECC 情報が占める割合が増えすぎてしまい、ユーザー データの格納に使用できる領域が圧迫されているのです。このことが、他のさまざまな要素と共に、より大きなセクター サイズの導入を後押ししています。

より大きなセクター サイズ: "Advanced Format" メディア

セクター サイズの拡大によって、新しい方式で ECC のエンコードを行うことが可能になります。これによってエラー修正の効率が増すと共に、全体的なディスク使用量も削減されます。この効率性は、将来的にさらに大容量のディスクを実現するうえでも役立ちます。ハード ディスク メーカー各社の合意によって採用された 4 KB の新しいセクター サイズは "Advanced Format (AF)" と呼ばれ、2009 年後半には最初の AF ドライブが市場に登場しています。以来各社は、将来的にはすべての記憶装置でこのフォーマットが使用されるという予測の下、製品のラインアップを急速に AF メディアへと移行させてきました。

Read-Modify-Write 処理

AF ディスクでは、データは 4 KB のブロック単位でメディア上に物理的に配置されています。メディアのデータの更新もこの精度でしかできないため、より小さな単位で論理ブロックのアドレスを行うためには、ディスク側で特別な処理が必要になります。物理セクター サイズの単位で書き込みを行う場合は特殊な処理は必要ではないため、物理セクター サイズをそのメディアの Atomicity (原子性) (英語) の単位と考えることができます。

下の図に示すように、4 KB の物理セクターは、512 バイトの論理セクターに分けて論理的にアドレス指定することができます。単一の論理セクターに書き込みを行う場合、単純に物理セクターのその部分にヘッドを動かして書き込むというわけにはいきません。代わりに、まず 4 KB の物理セクターをキャッシュに読み込み (Read)、キャッシュ内で 512 バイトの論理セクターを変更し (Modify)、最後に 4 KB の物理セクター全体をメディアに (元のブロックを上書きする形で) 書き戻します (Write)。これを Read-Modify-Write と呼びます。

このような非連動的な書き込みをサポートするためのエミレーション レイヤーを備えたディスクは、512 バイト エミュレーション付き 4K、または短縮して "512e" と呼ばれます。エミュレーション レイヤーを持たないディスクは "4K ネイティブ" と呼ばれます。

4 KB の物理セクターの中に 512 バイト単位の塊が 8 つ並んでいる。ステップ 1: 4K のセクターをメディアからキャッシュに読み込む。矢印。ステップ 2: 512 バイトの論理セクターをキャッシュ内で更新する (512 バイトのブロックの 1 つが強調表示されている)。ステップ 3: メディア上で元の 4K 物理セクターを上書きする。

Read-Modify-Write の採用によって、非連動的な書き込みが大量に発生するアプリケーションや作業負荷では、パフォーマンス低下が起きる可能性があります。この種のメディアをサポートするには、Windows 側ではアプリケーションが確実にデバイスの物理セクター サイズを取得できるようにする必要があり、アプリケーション側 (Windows アプリケーション、サード パーティ アプリケーションとも) では通知された物理セクター サイズに入出力を確実に連動させる必要があります。

大セクター ディスクに向けた設計

過去のバージョンの Windows で見られたいくつかの問題を踏まえて、Windows 8 では AF ディスクを新しい機能やテクノロジを設計するうえでの主要な考慮点として位置付けており、その結果 Windows 8 は 512e と 4K ネイティブ、両方の AF ディスクを完全にサポートする初の OS となっています。

これを実現するため、私たちは上記のような潜在的問題に対して最も脆弱性の高い機能や技術的な領域を特定し、その機能の開発を行っているチームに働きかけて、ガイダンスを提供すると共に、これらのシナリオに対応するハードウェア テスティングのサポートを行いました。

これによって、次のような改良を実現することができました。

  • アプリケーションがディスクの物理セクター サイズを取得しやすくするため、新しい API を導入すると共に既存の API を強化する
  • ファイル末尾への追加書き込みを行う際の適切なセクター パディングなど、NTFS ファイル システムの大セクター対応を強化する
  • Hyper-V が使用する新しい VHDx ファイル形式の大セクター対応を進め、両方の種類の AF ディスクをサポートする
  • 4K ネイティブ ディスクからでも Windows を問題なくブートできるよう、ブート コードを強化する

これらは、Windows 8 全体を両方の種類の AF ディスクに対応させるために注ぎ込まれている膨大な労力のごく一部に過ぎません。AF ディスクでの効率的で正確な動作を実現するため、Microsoft 内の他の製品チームや、業界を横断して他の関係者 (データベース アプリケーションの開発者など) とも連携して開発を進めています。

最後に

Windows 8 の NTFS は、業界のパートナー各社が提供する技術をフルに活用し、超大容量ディスクの効率的な扱いを実現します。超大容量ストレージへのニーズを余すところなく引き受ける NTFS と Windows 8 を楽しみにお待ちください。

/Bryan