Advanced Format (4K) のディスク互換性に関する最新情報

[アーティクル]
08/07/2024

プラットフォーム

クライアント Windows XP、Windows Vista、Windows 7、Windows 7 SP1、Windows 8
サーバー Windows Server 2003、Windows Server 2008、Windows Server 2008 R2、Windows Server 2008 R2 SP1、Windows Server 2012、Windows Server 2012 R2、Windows Server 2016

説明

この記事は、Windows 7 SP1 および Windows Server 2008 R2 SP1 向けにリリースされた、「512 バイトエミュレーション (512e) のディスク互換性に関する最新情報」というタイトルの記事の更新版です。この最新情報には多くの新しい情報が含まれています。その一部は Windows 8 および Windows Server 2012 にのみ適用されます。

面記録密度は年々向上しており、最近では 3 TB ディスクの登場により、信号対ノイズ比 (SNR) の低下に対処するために使用されるエラー訂正メカニズムのスペース効率が悪くなってきています。つまり、メディアが使用可能であることを保証するために、必要となるオーバーヘッド量が増加しています。このエラー訂正メカニズムを改善するためにストレージ業界が取り入れているソリューションの 1 つは、より大きな物理セクターサイズを含む別の物理メディア形式を導入することです。この新しい物理メディア形式が、Advanced Format と呼ばれるものです。したがって、最新のストレージデバイスのセクターサイズを想定することは、安全ではなくなりました。開発者はコードが何らかの想定に基づいていないか調べ、影響の有無を判断する必要があります。

このトピックでは、Advanced Format ストレージデバイスがソフトウェアに与える影響と、このタイプのメディアをサポートするためにアプリで何ができるかについて説明します。また、開発者がこれらの種類のデバイスをサポートできるように Microsoft が Windows Vista、Windows 7、および Windows 8 で導入したインフラストラクチャを紹介します。このトピックで紹介されている資料は、Advanced Format ディスクとの互換性を向上させるためのガイドラインを提供していますが、この情報は一般に、Windows Vista、Windows 7、および Windows 8 を実行している Advanced Format ディスクを備えたすべてのシステムに適用されます。

新しい大容量セクター関連機能の概要

以下の一覧は、大容量セクターディスクによってお客様および開発者のエクスペリエンス向上のために Windows 8 および Windows Server 2012 の一部として提供される新機能の概要です。各項目の詳細については、後で説明します。

エミュレーション付き 4K ディスク (512e) に対する Windows 7 SP1 サポートを基盤とし、エミュレーションなしの 4K セクターサイズのディスク (4K ネイティブ) に対する完全なインボックスサポートを提供します。次のようなアプリとシナリオがサポートされています。
- エミュレーションなしの 4K セクターディスクに Windows をインストールし、そこから起動する機能 (4K ネイティブディスク)
- VHD と新しい VHDX ファイル形式
- HyperV のフルサポート
- Windows バックアップ
- NT ファイルシステム (NTFS) でのフルサポート
- 新しいストレージスペースとプール (SSP) でのフルサポート
- Windows Defender でのフルサポート
物理セクターサイズ (FileFsSectorSizeInformation) を照会するための新しい API を提供します。
- ネットワークボリュームで使用可能
- 任意のファイルハンドルに対して発行可能
- 特権のないアプリで使用可能
- さらにわかりやすい使用モデル
ボリュームの論理および物理セクターサイズをアラインメント情報と共に照会するための拡張 fsutil コマンドラインユーティリティが含まれています (アラインメント情報のない基本バージョンのユーティリティは、Microsoft KB 982018 を適用した Windows 7 および Microsoft KB 982018 を適用した Windows Server 2008 R2 で使用できます)

Advanced Format (4K) ディスクの概要

メディア形式にこの変更を取り入れる際の問題の 1 つは、既存のソフトウェアやハードウェアとの互換性の問題が発生する可能性があることです。ストレージ業界では、一時的な互換性ソリューションとして、まず通常の 512 バイトセクターディスクをエミュレートしながら、標準の ATA および SCSI コマンドを通じて実際のセクターサイズに関する情報を提供するディスクから導入しています。このエミュレーションの結果、基本的には次の 2 つのセクターサイズが存在することになります。

論理セクター: メディアの論理ブロックアドレス指定に使用される単位。これは、ストレージが受け入れることができる書き込みの最小単位と考えることもできます。これがエミュレーションです。
物理セクター: デバイスに対する読み取り操作と書き込み操作が 1 回の操作で完了する単位。これはアトミックな書き込み単位です。
IOCTL_DISK_GET_DRIVE_GEOMETRY など、最新の Windows API では論理セクターサイズが返されますが、物理セクターサイズは、IOCTL_STORAGE_QUERY_PROPERTY 制御コードを使用して取得することもできます。関連する情報は、STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR 構造体の BytesPerPhysicalSector フィールドに含まれています。これについては、この記事で後ほど詳しく説明します。

大容量セクターメディアの初期タイプ

ストレージ業界では、物理セクターサイズが 4 KB のメディア用に、この新しい Advanced Format タイプのストレージに移行する取り組みが急速に進んでいます。市場にリリースされるメディアには次の 2 タイプがあります。

4 KB ネイティブ: このメディアにはエミュレーションレイヤーがなく、論理および物理セクターサイズとして 4 KB が直接公開されます。この新しいタイプのメディアの全体的な問題は、ほとんどのアプリとオペレーティングシステムが I/O を物理セクターサイズに照会して調整しないため、予期しない I/O の失敗が発生する可能性があるという点です。
512 バイトエミュレーション (512e): このメディアには、前のセクションで説明したエミュレーションレイヤーがあり、論理セクターサイズとして 512 バイト (現在の通常のディスクと同様) が公開されますが、物理セクターサイズ情報 (4 KB) も公開されます。この新しいタイプのメディアの全体的な問題は、ほとんどのアプリとオペレーティングシステムが物理セクターサイズの存在を認識していないため、以下で説明するような問題が発生する可能性があるという点です。
大容量セクターメディアに対する Windows の全体的なサポート

次の表は、さまざまなメディアおよびその結果として報告されるセクターサイズに関する Microsoft の公式サポートポリシーを示しています。詳細については、サポート技術情報の記事を参照してください。

共通名	報告された論理セクターサイズ	報告された物理セクターサイズ	サポートされている Windows バージョン
512 バイトネイティブ、512n	512 バイト	512 バイト	すべての Windows バージョン
Advanced Format、512e、AF、512 バイトエミュレーション	512 バイト	4 KB	Windows Vista (MS KB 2553708 適用) Windows Server 2008* (MS KB 2553708 適用) Windows 7 (MS KB 982018 適用) Windows Server 2008 R2* (MS KB 982018 適用) Windows 7 SP1 以降のすべての Windows バージョン。 Server 2008 R2 SP1 以降のすべての Server バージョン。 *Hyper-V を除く。「大容量セクタードライブのアプリケーションサポート要件」セクションを参照してください。
Advance Format、AF、4K ネイティブ、4Kn	4 KB	4 KB	Windows 8 以降のすべての Windows バージョン。 Windows Server 2012 以降のすべての Server バージョン
その他	4 KB または 512 バイト以外	4 KB または 512 バイト以外	サポートされていません

Note

前の表では強調されていませんが、Windows XP、Windows Server 2003、および Windows Server 2003 R2 では 512e または 4Kn メディアがサポートされていません。システムが起動して最小限の動作が可能な場合もありますが、機能上の問題、データの損失、または最適ではないパフォーマンスなど、未知のシナリオが発生する可能性があります。このため Microsoft では、Windows XP または Windows XP コードベースに基づくその他の製品 (Windows Home Server 1.0、Windows Server 2003、Windows Server 2003 R2、Windows XP 64 ビット版、Windows XP Embedded、Windows Small Business Server 2003、Windows Small Business Server 2003 R2 など) で 512e メディアを使用しないよう強く警告しています。

エミュレーションのしくみ: 読み取り/変更/書き込み (RMW)

ストレージメディアには、物理メディアを変更できる特定の単位があります。つまり、メディアは物理セクターサイズの単位でのみ書き込みまたは書き換えが可能です。したがって、この単位レベルで実行されない書き込みには、追加の手順が必要になります。これについては、以下の例で説明します。

このシナリオでは、アプリは 512 バイトの論理セクター内で Datastor レコードの内容を更新する必要があります。次の図は、ストレージデバイスが書き込みを完了するために必要な手順を示しています。

ストレージデバイスが書き込みを完了するための手順

上の図に示されているように、このプロセスにはストレージデバイスによる作業が伴い、それがパフォーマンスの低下につながる可能性があります。この追加作業を回避するには、以下が行われるようにアプリを更新する必要があります。

物理セクターサイズを照会する
報告された物理セクターサイズに書き込みがアラインされていることを確認する

これは最初はパフォーマンスの問題だけのように思えるかもしれませんが、より深刻な問題が存在している可能性があります。これについては次のセクションで説明します。

回復性: 読み取り/変更/書き込みの隠れたコスト

回復性とは、セッション間で状態を回復するアプリの能力を指します。ここまでで、512e ストレージデバイスが 512 バイトのセクター書き込み (読み取り/変更/書き込みサイクル) を実行するために何が必要かを説明しました。では、メディア上の以前の物理セクターを上書きするプロセスが中断された場合は、どうなるかを見てみましょう。どのような結果になるでしょうか?

ほとんどのハードディスクドライブは所定の位置で更新されるため、物理セクター (メディアのうち、物理セクターが存在する部分) が、部分的な上書きによる不完全な情報で破損している可能性があります。言い換えれば、物理セクターに論理的に含まれている 8 つの論理セクターすべてが失われた可能性があると考えることができます。
データストアを使用するほとんどのアプリは、メディアエラーから回復する機能を備えて設計されていますが、8 つのセクターが失われると (8 つのコミットレコードが失われると)、データストアが正常に回復できなくなる可能性があります。管理者は、バックアップからデータベースを手動で復元したり、長時間の再構築を実行するなどの作業が必要になる場合があります。
もう 1 つの重要な影響は、アプリが実行されていなくても、別のアプリで生じる読み取り/変更/書き込みサイクルによって、データが失われる可能性があるという点です。その原因は単純に、データが他のアプリのデータと同じ物理セクター内に配置される可能性があるためです。

これを念頭に置いて、アプリソフトウェアでは、コードで採用されている想定内容を再評価し、論理セクターサイズと物理セクターサイズの違いと、この記事で後述するお客様シナリオに注意することが重要です。

推奨プラクティス (読み取り/変更/書き込みの回避)

一部のストレージベンダーは、読み取り/変更/書き込みサイクルのパフォーマンスと回復性の問題を緩和するために、特定の 512e ストレージデバイス内に一定レベルの緩和策を導入している可能性がありますが、ワークロードという点では、緩和策で処理できる量には限界があります。このため、アプリでは長期的な解決策としてこの緩和策に依存しないでください。さらに、すべてのクラスのディスクにこの軽減策が講じられているという保証はなく、軽減策が適切に設計されているという保証もありません。

これに対する解決策は、ドライブ内の軽減策ではなく、このタイプのメディアのサポートに役立つ適切な一連の処理が行われるようにアプリを設計することです。このセクションでは、大容量セクターディスクでアプリに問題が発生する可能性のある一般的なシナリオについて説明し、各問題を解決するための調査手順を提案します。

問題 1: パーティションが物理セクターの境界にアラインされていない

管理者/ユーザーがディスクをパーティション分割するときに、最初のパーティションが境界にアラインして作成されていない可能性があります。このような場合、後続のすべての書き込みが物理セクター境界に合わなくなる可能性があります。 Windows Vista SP1 および Windows Server 2008 では、最初のパーティションは、4 KB の物理セクター境界にアラインして、ディスクの先頭 1024 KB (4 GB 以上のディスクの場合。それ以外の場合のアラインメントは 64 KB) に配置されます。ただし、Windows XP での既定のパーティション分割、サードパーティ製のパーティション分割ユーティリティ、または Windows API の不適切な使用などにより、作成されたパーティションが物理セクターの境界に合っていない可能性があります。開発者は、適切な API を使用して確実なアラインメントを行う必要があります。パーティションのアラインメントを確実に行うために推奨される API の概要を次に示します。

IVdsPack::CreateVolume および IVdsPack2::CreateVolume2 API では、新しいボリュームを作成するときに、指定されたアラインメントパラメーターではなく、オペレーティングシステムの既定のアラインメント値が使用されます (Windows Vista SP1 より前は 63 バイトを使用し、Windows Vista SP1 以降は上記の既定値を使用)。代わりに、パーティションを作成する必要があるアプリに対して指定のアラインメントパラメーターが使用される IVdsCreatePartitionEx::CreatePartitionEx または IVdsAdvancedDisk::CreatePartition API をお使いください。

アラインメントが正しいことを確認するための最善の方法は、パーティションを最初に作成するときに正しく行うことです。そうしないと、書き込みの実行時や初期化時にアプリでアラインメントを考慮する必要があり、非常に複雑なプロセスになる可能性があります。

問題 2: バッファーなしの書き込みが物理セクターサイズにアラインされていない

最も単純な問題は、バッファーなしの書き込みが、報告されたストレージメディアの物理セクターサイズにアラインされていないことです。一方、バッファー書き込みは、第 1 世代の大容量セクターメディアの物理セクターサイズと一致するページサイズである 4 KB に合わせてアラインされます。ただし、データストアを備えたほとんどのアプリではバッファーなしの書き込みが実行されるため、これらの書き込みが物理セクターサイズの単位で実行されるようにする必要があります。

結果として生じるアプリ I/O がアラインされないシナリオの例を次に示します。

コミットレコードは 512 バイトのセクターに合わせてパディングされる: データストアを備えたアプリには通常、メタデータの変更に関する情報やデータストアの構造の管理に使用される、何らかの形式のコミットレコードがあります。セクターの損失が複数のレコードに影響しないようにするために、このコミットレコードは通常、セクターサイズに合わせてパディングされます。物理セクターサイズが大きいディスクの場合は、前のセクションに示したようにアプリで物理セクターサイズを照会し、各コミットレコードがそのサイズに合わせてパディングされるようにする必要があります。 4K ディスクでは、これによって I/O の失敗がなくなります。 512e ディスクでは、読み取り/変更/書き込みサイクルを回避できるだけでなく、物理セクターが失われた場合にコミットレコードの損失を 1 件に限定するために役立ちます。
ログファイルが、アラインされていないチャンクで書き込まれる: ログファイルの更新時や追加時には通常、バッファなし I/O が使用されます。アプリは、バッファリングされた I/O に切り替えるか、ログの更新を物理セクターサイズの単位で内部的にバッファリングして、I/O の失敗や読み取り/変更/書き込みのトリガーを回避できます。
バッファリングされていない I/O をアプリから発行するかどうかを判断するには、CreateFile 関数を呼び出すときに、dwFlagsAndAttributes パラメーターに FILE_FLAG_NO_BUFFERING フラグを含めます。

さらに、現在書き込みをセクターサイズにアラインしている場合、そのセクターサイズは論理セクターサイズのみである可能性が高くなります。メディアのセクターサイズを照会するほとんどの既存 API が、アドレス指定の単位 (論理セクターサイズ) だけを照会しているためです。ここで必要なセクターサイズは物理セクターサイズであり、これが実際の不可分な単位です。論理セクターサイズを取得する API の例を次に示します。

GetDiskFreeSpace、GetDiskFreeSpaceEx
FileFsVolumeInformation
IOCTL_DISK_GET_DRIVE_GEOMETRY、IOCTL_DISK_GET_DRIVE_GEOMETRY_EX
IVdsDisk::GetProperties、IVdsDisk3::GetProperties2

物理セクターサイズを照会する方法を次に示します。

Windows 8 で推奨される方法

Windows 8 では、開発者がアプリに 4K サポートを簡単に統合できる新しい API が導入されました。この新しい API では、以下で説明する Windows Vista および Windows 7 の従来の方法よりさらに多くのシナリオがサポートされています。この API を使用すると、次のような呼び出しのシナリオが可能になります。

特権のないアプリからの呼び出し
任意の有効なファイルハンドルの呼び出し
SMB2 経由でのリモートボリューム上のファイルハンドルの呼び出し
簡素化されたプログラミングモデル

この API は、新しい情報クラス FileFsSectorSizeInformation の形式で提供されており、関連付けられた構造体 FILE_FS_SECTOR_SIZE_INFORMATION は次のように定義されます。

typedef struct _FILE_FS_SECTOR_SIZE_INFORMATION {  
    ULONG LogicalBytesPerSector;  
    ULONG PhysicalBytesPerSectorForAtomicity;  
    ULONG PhysicalBytesPerSectorForPerformance;  
    ULONG FileSystemEffectivePhysicalBytesPerSectorForAtomicity;  
    ULONG Flags;  
    ULONG ByteOffsetForSectorAlignment;  
    ULONG ByteOffsetForPartitionAlignment;  
} FILE_FS_SECTOR_SIZE_INFORMATION, *PFILE_FS_SECTOR_SIZE_INFORMATION;

Windows 7 および Windows Vista での従来の方法

Windows Vista および Windows Server 2008 では、AHCI ベースのストレージコントローラー用に接続されているストレージデバイスの物理セクターサイズを照会する API が導入されました。 Windows 7 および Windows Server 2008 R2 では、SP1 (または Microsoft サポート技術情報 982018) 以降、このサポートが Storport ベースのストレージコントローラーに拡張されています。ボリュームの物理セクターサイズをアプリから照会する方法を示したコードサンプルについては、「STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR 構造体」を参照してください。

上記のコードサンプルを使用すると、ボリュームの物理セクターサイズを取得できますが、一部のドライバーでは正しいフォーマットのデータが返されない場合があるため、使用する前に、報告された物理セクターサイズの基本的なサニティチェックを行う必要があります。

報告された物理セクターサイズ >= 報告された論理セクターサイズであることを確認します。そうでない場合、アプリでは報告された論理セクターサイズと同じ物理セクターサイズを使用する必要があります。
報告される物理セクターサイズが 2 の累乗であることを確認します。そうでない場合、アプリでは報告された論理セクターサイズと同じ物理セクターサイズを使用する必要があります。
物理セクターサイズが 512 バイトから 4KB までの 2 の累乗値である場合は、報告された論理セクターサイズまで切り捨てた物理セクターサイズの使用を検討する必要があります。
物理セクターサイズが 4 KB を超える 2 の累乗値である場合は、その値を使用する前に、アプリでこのシナリオを処理できるかどうかを評価する必要があります。そうでない場合は、4 KB に切り捨てた物理セクターサイズの使用を検討する必要があります。

この IOCTL を使用して物理セクターサイズを取得する場合は、次のような制限があります。

昇格された特権が必要です。アプリが特権で実行されていない場合は、上記のように Windows サービスアプリケーションを作成する必要がある場合があります。
SMB ボリュームはサポートされません。SMB ボリュームの物理セクターサイズを照会できるようにするには、Windows サービスアプリケーションの作成が必要になる場合もあります。
ファイルハンドルには発行できません (IOCTL はボリュームハンドルに発行する必要があります)。

問題 3: 512 バイトのセクターに依存するファイル形式

標準ファイル形式 (VHD 1.0 など) を使用する一部のアプリでは、512 バイトのセクターサイズを想定してこれらのファイルがハードコーディングされている場合があります。そのため、このファイルの更新と書き込みにより、デバイス上で読み取り/変更/書き込みのサイクルが発生し、お客様から見てパフォーマンスと回復性の問題が生じる可能性があります。ただし、このタイプのメディアでアプリが動作できるよう、次のようにサポートを提供する方法があります。

バッファリングを使用して、物理セクターサイズの単位で書き込みが実行されるようにする。
内部の読み取り/変更/書き込みを実装する。これにより、報告された物理セクターサイズの単位で更新が確実に実行されるようになります。
可能であれば、レコードを物理セクターにパディングする。これにより、パディングが空きスペースとして解釈されるようになります。
より大きなセクターをサポートできるように、アプリデータ構造の再設計を検討する

問題 4: 報告される物理セクターのサイズがセッション間で変化する可能性がある

Datastor をホストする基盤となるストレージについて、報告された物理セクターサイズが変化するシナリオは多数あります。最も一般的なシナリオは、Datastor を別のボリュームに移行する場合、またはネットワーク経由で移行する場合です。報告される物理セクターサイズの変化は、多くのアプリで予期しないイベントである可能性があり、一部のアプリでは再初期化の失敗につながることがあります。

これはサポートが容易なシナリオではないため、ここではアドバイスとして記載しています。 4K ネイティブまたは 512e メディアの使用によって、お客様にマイナスの影響が及ばないように、お客様のモビリティ要件を考慮してサポートを調整する必要があります。

ユーザーがボリュームの論理セクターサイズと物理セクターサイズを取得する方法

Windows には、ボリュームのセクターサイズ情報を表示するユーティリティが付属しています。 fsutil がサポートされている Windows のバージョンは次のとおりです。

Windows 8
Windows Server 2012
Windows 7 SP1 (Microsoft KB 982018 を適用)
Windows 7 (Microsoft KB 982018 を適用)
Windows Server 2008 R2 SP1 (Microsoft KB 982018 (v3) を適用)
Windows Server 2008 R2 (Microsoft KB 982018 (v3) を適用)
Windows Vista (Microsoft KB 2553708 を適用)
Windows Server 2008 (Microsoft KB 2553708 を適用)

セクターサイズ情報を取得するには、管理者特権のコマンドプロンプトから次のようにユーティリティを呼び出します。

fsutil fsinfo ntfsinfo <drive letter>

512 バイトエミュレーションを備えた 4K セクターディスクでは、次のように [セクターあたりのバイト数] フィールドが 512 に設定され、[物理セクターあたりのバイト数] フィールドが 4096 に設定されています。

512 バイトエミュレーションを備えた 4K セクターディスクのセクターあたりのバイト数と物理セクターあたりのバイト数

4K ネイティブディスクでは、次のように [セクターあたりのバイト数] フィールドと [物理セクターあたりのバイト数] フィールドの両方が 4096 に設定されています。

4k ネイティブディスクのセクターあたりのバイト数と物理セクターあたりのバイト数

Note

[物理セクターあたりのバイト数] フィールドに [サポートされていません] と表示される場合は、ストレージドライバーが IOCTL_STORAGE_QUERY_PROPERTY をサポートしていないか、情報の取得中にエラーが発生しています。

次の方法で共有

Advanced Format (4K) のディスク互換性に関する最新情報

プラットフォーム

説明

エミュレーションのしくみ: 読み取り/変更/書き込み (RMW)

リソース

フィードバック

その他のリソース