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つは、より大きな物理セクターサイズを含む別の物理メディアフォーマットを導入することです。 この新しい物理メディア形式は、 高度な形式 と呼ばれます。 そのため、最新の記憶装置のセクターサイズに関してはいかなる仮定もできなくなり、影響があるかどうかを判断するために、開発者はコードの基になる前提を調べる必要があります。

このトピックでは、高度なフォーマットのストレージデバイスのソフトウェアへの影響、この種類のメディアをサポートするためにアプリケーションが実行できることについて説明し、開発者がこれらの種類のデバイスをサポートできるようにするためのインフラストラクチャについて説明します。 このトピックで説明する資料には、高度なフォーマットディスクとの互換性を向上させるためのガイドラインが記載されていますが、一般に、高度なフォーマットディスクを使用するすべてのシステムに情報が適用されます。 次のバージョンの 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
  • Microsoft KB 2553708 を使用した Windows Server 2008

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

詳細なフォーマットディスクの詳細については、記憶域のベンダーにお問い合わせください。

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

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

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

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

Ioctl _ DISK _ GET _ DRIVE _ GEOMETRY などの最新の Windows api は、論理セクターサイズを返しますが、物理的なセクターサイズは、 ioctl _ ストレージクエリの _ _ プロパティコントロールコードを使用して取得できます。これには、ストレージ _ アクセス _ アラインメント _ 記述子構造の bytesperphysicalsector フィールドに含まれる関連情報が含まれています。 詳細については、この記事の後半で詳しく説明します。

大きなセクターメディアの初期タイプ

ストレージ業界は、4 KB の物理セクターサイズのメディア用に、この新しい高度なフォーマットの種類の記憶域に移行するための作業を迅速に開始します。 次の2種類のメディアが市場にリリースされます。

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

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

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

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

512バイトの論理セクター内で datastor レコードをアップグレードするために必要な手順

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

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

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

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

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

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

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

これを念頭に置いて、アプリケーションソフトウェアは、コードで想定されているすべての前提を再評価し、論理物理セクターサイズの区別に加え、この記事の後半で説明するいくつかの興味深い顧客シナリオを認識していることが重要です。

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

読み取り/書き込み/書き込みの回避

一部の記憶域ベンダーでは、読み取り/書き込みサイクルのパフォーマンスと回復性の問題を軽減するために、特定の512e ストレージデバイス内で何らかのレベルの軽減策が導入されている場合がありますが、ワークロードの観点からは、軽減策はほとんどしか処理できません。 そのため、アプリケーションでは、長期的な解決策として、この軽減策に依存しないでください。

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

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

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

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

配置が正しいことを確認する最善の方法は、最初にパーティションを作成するときに適切な方法です。 それ以外の場合、アプリケーションは、書き込みを実行するときや初期化時に配置を考慮する必要があります。これは非常に複雑な場合があります。 Windows Vista SP1 以降では、これは通常は問題ではありません。ただし、以前のバージョンの Windows では、一部の高度なフォーマットディスクでパフォーマンスの問題につながる可能性がある、整列されていないパーティションを作成できます。

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

基本的な問題は、バッファーに格納されていない書き込みが、記憶域メディアの報告された物理セクターサイズに対応していないことです。これにより、ドライブに読み取り/書き込み/書き込みが発生し、パフォーマンスの問題が発生する可能性があります。 一方、バッファーに書き込まれた書き込みはページサイズ (4 KB) に合わせて調整されます。これは、coincidently が最初に生成された大きなセクターメディアの物理セクターサイズです。 ただし、データストアを使用するほとんどのアプリケーションは、バッファーなしの書き込みを実行するため、これらの書き込みが物理的なセクターサイズの単位で実行されるようにする必要があります。

アプリケーションでバッファーされない i/o が発生しているかどうかを判断するには、 CreateFile 関数を呼び出すときに、 DwFlagsAndAttributes パラメーターに FILE _ フラグ _ NO _ バッファリング フラグを含めることを確認します。

さらに、現在、書き込みをセクターサイズに合わせて調整している場合、このセクターサイズは 論理 セクターサイズにすぎません。これは、メディアのセクターサイズをクエリする既存の api が、単にアドレス指定の単位 (つまり、論理セクターのサイズ) に対してクエリを実行することです。 ここでのセクターサイズは、原子性の実際の単位である物理セクターサイズです。 論理セクターサイズを取得する Api の例を次に示します。

  • Getdiskfreespace 領域、 GetDiskFreeSpaceEx
  • FileFsVolumeInformation
  • IOCTL _DISK _ GET _ DRIVE _ GEOMETRYIOCTL _ DISK _ GET _ DRIVE _ GEOMETRY _ EX
  • IVdsDisk:: GetPropertiesIVdsDisk3:: 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 でこれらの種類のメディアのサポートを調査しており、必要に応じてサポート技術情報の記事を発行する予定ですが、アプリケーション開発者は、これらの種類のメディアのサポートを提供する事前にを検討する必要があります。

閉じる

この記事では、多くの一般的な展開シナリオで、大きなセクターメディアによって生じる影響について説明しました。 ここでは、読み取り/書き込み/書き込みのパフォーマンスと回復性の影響、このメディアによって導入される可能性のあるいくつかのシナリオ、および最終的にエンドユーザーに影響を与えるソフトウェアで発生する可能性がある問題のセットについて説明しました。 ストレージ業界は、セクターサイズが大きいメディアに急速に移行しています。また、近日中のお客様は、従来の512バイトのセクターサイズでディスクを購入することはできません。

これは生きたドキュメントであり、開発者がこの遷移を理解するのに役立ちます。 各組織との会話を開始し、お客様、IT 技術者、ハードウェアベンダーが、大きなセクターの移行と、それが重要なシナリオにどのように影響するかについて話します。