高度な形式 (4K) ディスク互換性の更新

[アーティクル]
06/13/2023

プラットフォーム

クライアント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 ストレージデバイスの効果について説明し、この種類のメディアをサポートするためにアプリができることについて説明し、開発者がこれらの種類のデバイスをサポートできるようにするための Windows Vista、Windows 7、Windows 8で Microsoft が導入したインフラストラクチャについて説明します。このトピックで説明する資料は、Advanced Format ディスクとの互換性を向上させるためのガイドラインを提供しますが、この情報は一般に、Windows Vista、Windows 7、およびWindows 8を実行する Advanced Format ディスクを持つすべてのシステムに適用されます。

新しい大規模セクター関連機能の概要

次の一覧は、Windows 8とWindows Server 2012の一部として提供される新機能をまとめたものです。これは、大規模なセクターディスクでの顧客と開発者のエクスペリエンスを向上させるのに役立ちます。各項目の詳細な説明については、以下を参照してください。

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

高度な形式 (4K) ディスクの概要

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

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

大規模セクターメディアの初期タイプ

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

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

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

共通名	報告された論理セクターサイズ	報告された物理セクターのサイズ	サポート付きの Windows バージョン
512 バイトネイティブ、512n	512 バイト	512 バイト	すべての Windows バージョン
高度な形式、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* w/ MS KB 982018 Windows 7 SP1 以降のすべての Windows バージョン。 Server 2008 R2 SP1 以降のすべてのサーバーバージョン。 *Hyper-V を除く。「大規模セクタードライブのアプリケーションサポート要件」セクションを参照してください。
アドバンスフォーマット、AF、4Kネイティブ、4Kn	4 KB	4 KB	Windows 8以降のすべての Windows バージョン Windows Server 2012以降のすべてのサーバーバージョン
その他	4 KB または 512 バイトではない	4 KB または 512 バイトではない	サポートされていません

注意

前の表ではストレスを受けませんが、Windows XP、Windows Server 2003、および Windows Server 2003 R2 では 512e または 4Kn メディアはサポートされていません。システムが起動し、最小限に動作できる場合がありますが、機能の問題、データ損失、または最適なパフォーマンスが低下する不明なシナリオが存在する可能性があります。したがって、Microsoft は、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 など) に基づく Windows XP またはその他の製品で 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 は、新しいボリュームの作成時に指定された配置パラメーターを使用せず、オペレーティングシステムの配置値の既定値を使用します (Pre-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 は、新しい info クラス 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 ベースのストレージコントローラーに拡張されます。 Microsoft は、ボリュームの物理セクターサイズに対してアプリがクエリを実行する方法を詳しく説明するコードサンプルを MSDN で提供しています。

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

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

この IOCTL を使用して物理セクターのサイズを取得するには、いくつかの制限があります。それでは次のことが行われます。

昇格された特権が必要です。アプリが特権で実行されていない場合は、上記のように Windows サービスアプリケーションを記述する必要がある場合があります
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 セクターディスクの [Bytes Per Sector]\(セクターあたりのバイト数\) フィールドは 512 に設定され、[Bytes Per Physical Sector]\(物理セクターあたりのバイト数\) フィールドは次のように 4096 に設定されています。

512 バイトエミュレーションを使用する 4k セクターディスクのセクターあたりのバイト数と物理セクターあたりのバイト数

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

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

注意

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

高度な形式 (4K) ディスク互換性の更新

プラットフォーム

説明

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

リソース

フィードバック

フィードバック

その他のリソース