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

  • [アーティクル]

プラットフォーム

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

機能への影響

重大度 - 高
頻度 - 高

説明

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

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

  • Windows 7 と Microsoft KB 982018
  • Windows 7 SP1
  • Windows Server 2008 R2 と Microsoft KB 982018
  • Windows Server 2008 R2 SP1
  • Windows Vista と Microsoft KB 2553708
  • 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 の物理セクター サイズを持つメディア用に、この新しい Advanced Format タイプのストレージに移行する取り組みが急速に進んでいます。 2種類のメディアが市場にリリースされる予定です。

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

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

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

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

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 を使用することをお勧めします。この 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 担当者、ハードウェア ベンダーと、それぞれの組織との会話を開始して、大規模なセクターの移行と、それが重要なシナリオにどのように影響するかを話す必要があります。