512 バイト エミュレーション (512e) ディスク互換性更新プログラム

  • [アーティクル]

プラットフォーム

クライアント - Windows Vista、Windows 7、Windows 7 SP1
サーバー - Windows Server 2008、Windows Server 2008 R2、Windows Server 2008 R2 SP1

機能の影響

重大度 - 高
頻度 - 高

説明

Areal 密度は年々増加しており、最近の 3 TB ディスクの登場に伴い、信号対ノイズ比 (SNR) の減少に対処するために使用されるエラー修正メカニズムは、スペースが非効率的になりつつあります。つまり、メディアを確実に使用できるようにするためにオーバーヘッドの増加が必要になります。 このエラー修正メカニズムを改善するためのストレージ業界ソリューションの 1 つは、より大きな物理セクター サイズを含む別の物理メディア形式を導入することです。 この新しい物理メディア形式は 、高度な形式と呼ばれます。 そのため、最新のストレージ デバイスのセクター サイズに関する仮定を行っても安全ではなくなり、開発者はコードの基になる前提条件を調べて、影響があるかどうかを判断する必要があります。

このトピックでは、ソフトウェアに対する Advanced Format ストレージ デバイスの効果について説明し、この種のメディアをサポートするためにアプリケーションができることについて説明し、開発者がこれらの種類のデバイスをサポートできるようにするインフラストラクチャについて説明します。 このトピックで説明する資料は、Advanced Format ディスクとの互換性を向上させるガイドラインを提供しますが、この情報は通常、Advanced Format ディスクを持つすべてのシステムに適用されます。 次のバージョンのWindowsでは、物理セクター サイズのクエリをサポートしています。

  • Microsoft KB 982018 で 7 をWindowsする
  • Windows 7 SP1
  • Windows Server 2008 R2 と Microsoft KB 982018
  • Windows Server 2008 R2 SP1
  • Microsoft KB 2553708 を使用した Vista のWindows
  • Windows Server 2008 と Microsoft KB 2553708

詳細については、Windowsの大規模セクター ドライブに関する Microsoft サポート ポリシーに関する情報を参照してください。

Advanced Format ディスクの詳細については、ストレージ ベンダーにお問い合わせください。

論理セクターサイズと物理セクター サイズ

メディア形式でこの変更を導入する場合の懸念事項の 1 つは、現在市場で利用可能なソフトウェアとハードウェアとの互換性です。 ストレージ業界では、一時的なソリューションとして、最初は通常の 512 バイト セクター ディスクをエミュレートするディスクを導入していますが、標準の ATA および SCSI コマンドを使用して、実際のセクター サイズに関する情報を入手できます。 このエミュレーションの結果、次の 2 つのセクター サイズがあります。

  • 論理セクター: メディアの論理ブロック アドレス指定に使用される単位。 また、ストレージが受け入れられる最小の書き込み単位と考えることもできます。 これがエミュレーションです。

  • 物理セクター: デバイスへの読み取り操作と書き込み操作が 1 回の操作で完了する単位。 これはアトミック書き込みの単位です。

IOCTL_DISK_GET_DRIVE_GEOMETRYなどの最新のWindows API は論理セクター サイズを返しますが、物理セクター サイズは、STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR構造体の BytesPerPhysicalSector フィールドに含まれる関連情報を使用して、IOCTL_STORAGE_QUERY_PROPERTY制御コードを介して取得できます。 これについては、この記事の後半で詳しく説明します。

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

ストレージ業界では、物理セクター サイズが 4 KB のメディア用に、この新しい高度な形式のストレージに移行する取り組みが急速に強化されています。 2 種類のメディアが市場にリリースされます。

  • 4 KB ネイティブ: このメディアにはエミュレーション レイヤーがなく、論理セクターサイズと物理セクター サイズとして 4 KB が直接公開されます。 このメディアは現在、Windowsやその他のほとんどのオペレーティング システムではサポートされていません。 ただし、Microsoft は今後のバージョンのWindowsでこの種のメディアをサポートする可能性について調査を行っており、必要に応じてサポート技術情報の記事を発行します。
  • 512 バイト エミュレーション (512e): このメディアには、前のセクションで説明したようにエミュレーション レイヤーがあり、論理セクター サイズとして 512 バイトが公開されますが (現在の通常のディスクと同様)、物理セクター サイズ情報 (4 KB) が使用可能になります。 これは、複数のストレージ ベンダーが現在市場に導入しているものです。 この新しい種類のメディアに関するこの全体的な問題は、アプリケーションとオペレーティング システムの大部分が物理セクター サイズの存在を理解していないため、以下で説明するように多くの問題が発生する可能性があることです。

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

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

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

steps needed to upgrade datastor record within a 512-byte logical sector

上に示したように、このプロセスには、パフォーマンスが低下する可能性があるストレージ デバイスによる作業が含まれます。 この追加作業を回避するには、次の操作を行うためにアプリケーションを更新する必要があります。

  • 物理セクター サイズを照会します。
  • 書き込みが報告された物理セクター サイズに合わせて配置されていることを確認します。

読み取り/変更/書き込みの回復性の影響

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

  • ほとんどのハード ディスク ドライブが正しく更新されるため、物理セクター (つまり、物理セクターが配置されたメディアの一部) が、部分的な上書きのために不完全な情報で破損している可能性があります。 言い換えると、8 つの論理セクター (物理セクターに論理的に含まれる) がすべて失われた可能性があると考えることができます。

  • データ ストアを使用するほとんどのアプリケーションは、メディア エラーから回復する機能を備えて設計されていますが、8 つのセクターが失われたり、別の方法で言い換えたりすると、8 つのコミット レコードが失われると、データ ストアが正常に回復できなくなる可能性があります。 管理者は、バックアップからデータベースを手動で復元する必要がある場合や、長い再構築を実行する必要がある場合もあります。

  • もう 1 つの重要な影響は、読み取り/変更/書き込みサイクルを引き起こす別のアプリケーションの動作によって、アプリケーションが実行されていない場合でも、データが失われる可能性があるということです。 これは、データと他のアプリケーションのデータが同じ物理セクター内に配置される可能性があるからです。

これを念頭に置いて、アプリケーション ソフトウェアがコードで取られた前提条件を再評価し、論理物理セクター サイズの区別と、この記事で後述するいくつかの興味深い顧客シナリオに注意することが重要です。

この問題は、アプリケーションがログ構造データ ストアに依存している場合に発生する可能性が高くなります。

読み取り/変更/書き込みを回避する

一部のストレージ ベンダーは、読み取り/変更/書き込みサイクルのパフォーマンスと回復性の問題を緩和するために、特定の 512e ストレージ デバイス内に一部のレベルの軽減策を導入している可能性がありますが、ワークロードに関して処理できる軽減策は非常に多くしかありません。 そのため、アプリケーションはこの軽減策を長期的なソリューションとして利用しないでください。

これに対する解決策は、ドライブ内の軽減策ではなく、読み取り/変更/書き込みサイクルを回避するためにアプリケーションに適切な一連の処理を行ってもらうことです。 このセクションでは、アプリケーションが大規模なセクター ディスクに問題を抱えている可能性がある一般的なシナリオについて説明し、各問題を解決するための調査手段を提案します。

問題 1: パーティションが物理セクターの境界に揃っていない

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

IVdsPack::CreateVolume および IVdsPack2::CreateVolume2 API は、新しいボリュームの作成時に指定された配置パラメーターを使用せず、代わりにオペレーティング システムの配置値の既定値を使用します (Pre-Windows Vista SP1 は 63 バイトを使用し、vista SP1 Windows後は上記の既定値を使用します)。 したがって、パーティションを作成する必要があるアプリケーションでは、代わりに IVdsCreatePartitionEx::CreatePartitionEx または IVdsAdvancedDisk::CreatePartition API を使用することをお勧めします。この API では、指定した配置パラメーターを使用します。

配置が正しいことを確認する最善の方法は、パーティションを最初に作成するときに正しく行うことです。 そうしないと、書き込みを実行するとき、または初期化時にアプリケーションがアラインメントを考慮する必要があります。これは非常に複雑な問題になる可能性があります。 Windows Vista SP1 の時点では、これは一般的に問題ではありません。ただし、古いバージョンのWindowsでは、一部の Advanced Format ディスクでパフォーマンスの問題が発生する可能性がある、配置されていないパーティションが作成される可能性があります。

問題 2: バッファーなしの書き込みが物理セクター サイズに一致しない

基本的な問題は、バッファーなしの書き込みがストレージ メディアの報告された物理セクター サイズに合わないため、ドライブ内で読み取り/変更/書き込みがトリガーされ、パフォーマンスの問題が発生する可能性があります。 一方、バッファー書き込みはページ サイズ (4 KB) に揃えられます。これは、一致して、第 1 世代の大規模セクター メディアの物理セクター サイズです。 ただし、データ ストアを使用するほとんどのアプリケーションはバッファーなしの書き込みを実行するため、これらの書き込みが物理セクター サイズの単位で実行されるようにする必要があります。

アプリケーションでバッファーなしの 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

物理セクター サイズを照会する方法

Microsoft は、アプリケーションがボリュームの物理セクター サイズを照会する方法を詳しく説明した MSDN のコード サンプルを提供しています。 コード サンプルは ..https://msdn.microsoft.com/library/ff800831.aspx

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

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

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

  • 管理者特権が必要です。 アプリケーションが特権で実行されていない場合は、前述のようにWindowsサービス アプリケーションを記述する必要があります。

  • SMB ボリュームはサポートされていません。 また、これらのボリュームに対する物理セクター サイズのクエリをサポートするために、Windows サービス アプリケーションを記述する必要がある場合もあります。

  • どのファイル ハンドルにも発行できません (IOCTL はボリューム ハンドルに発行する必要があります)。

  • この記事の冒頭に記載されているWindowsバージョンでのみサポートされます。

コミット レコードが 512 バイトのセクターに埋め込まれる

通常、データ ストアを持つアプリケーションには、メタデータの変更に関する情報を保持するか、データ ストアの構造を維持する何らかの形式のコミット レコードがあります。 セクターの損失が複数のレコードに影響しないようにするため、通常、このコミット レコードはセクター サイズに埋め込まれます。 物理セクター サイズが大きいディスクでは、アプリケーションは前のセクションに示すように物理セクター サイズを照会し、各コミット レコードがそのサイズに埋め込まれるようにする必要があります。 これにより、読み取り/変更/書き込みサイクルが回避されるだけでなく、物理セクターが失われた場合に 1 つのコミット レコードのみが失われることを保証するのに役立ちます。

ログ ファイルは整列されていないチャンクで書き込まれます

バッファーなしの I/O は、通常、ログ ファイルを更新または追加するときに使用されます。 これらの更新プログラムが正しく配置されていることを確認するには、いくつかの方法があります。

  • オペレーティング メディアの報告された物理セクター サイズに対するログの更新を内部的にバッファーし、物理セクター ユニットがいっぱいの場合にのみログ書き込みを発行する
  • バッファー付き I/O を使用する

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

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

  • バッファー処理を使用して、物理セクター サイズの単位で書き込みが実行されるようにする
  • 報告された物理セクター サイズの単位で更新が確実に実行されるようにするために役立つ内部読み取り/変更/書き込みを実装する
  • 可能であれば、埋め込みが空の領域として解釈されるように、パッドは物理セクターに記録します
  • より大きなセクターをサポートする新しいバージョンのアプリケーション データ構造の再設計を検討する

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

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

これは、サポートする最も簡単なシナリオではなく、ここではアドバイザリとして説明されています。 顧客のモビリティ要件を考慮し、それに応じてサポートを調整して、512e メディアを使用して顧客が悪影響を受けないようにする必要があります。

4 KB のネイティブ メディア

512 バイトのエミュレーション メディアは、512 バイトのネイティブ メディアと 4 KB ネイティブ メディアの移行ステップとして意図されており、512e が使用可能になるとすぐに 4 KB ネイティブ メディアがリリースされる予定です。 このメディアには、次のような重要な影響があります。

  • 論理セクター サイズと物理セクター サイズはどちらも 4 KB です。
  • エミュレーション 層がないため、配置されていない書き込みはストレージによって失敗します
  • 隠れた回復性のヒットなし - アプリケーションが動作するか、動作しない

Microsoft は現在、将来のバージョンのWindowsでこれらの種類のメディアのサポートを調査しており、必要に応じて KB 記事を発行しますが、アプリケーション開発者は、これらの種類のメディアのサポートを事前に提供することを検討する必要があります。

閉じる

この記事では、多数の一般的な展開シナリオで大規模セクター メディアが導入する影響について説明しました。 読み取り/変更/書き込みのパフォーマンスと回復性の影響、このメディアが導入できる興味深いシナリオの一部、およびソフトウェアで発生する可能性のある一連の問題が見られました。これは最終的にエンドユーザーに影響します。 ストレージ業界は、セクター サイズが大きいメディアに急速に移行しており、間もなくお客様は従来の 512 バイトのセクター サイズのディスクを購入できなくなります。

これは生きたドキュメントであり、開発者がこの移行を理解するための支援として意図されています。 顧客、IT 担当者、ハードウェア ベンダーと、それぞれの組織との会話を開始して、大規模なセクターの移行と、それが重要なシナリオにどのような影響を与えるかについて話し合う必要があります。