次の方法で共有

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 ディスクとの互換性を向上させるためのガイドラインを提供していますが、この情報は一般に、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 では論理セクター サイズが返されますが、物理セクター サイズは、IOCTL_STORAGE_QUERY_PROPERTY 制御コードを使用して取得することもできます。関連する情報は、STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR 構造体の BytesPerPhysicalSector フィールドに含まれています。 これについては、この記事で後ほど詳しく説明します。

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

ストレージ業界では、物理セクター サイズが 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: バッファーなしの書き込みが物理セクター サイズにアラインされていない

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

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

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

ボリュームの物理セクター サイズをアプリケーションから照会する方法を示したコード サンプルについては、https://msdn.microsoft.com/library/ff800831.aspx を参照してください。

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

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

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

  • 昇格された特権が必要です。 アプリケーションが特権で実行されていない場合は、上記のように Windows サービス アプリケーションを作成する必要がある場合があります。

  • SMB ボリュームはサポートされません。 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 でこれらのタイプのメディアをサポートできるかどうかについて調査を行っており、適切なタイミングでサポート技術情報の記事を公開する予定ですが、アプリケーション開発者は、これらのタイプのメディアへの先取りしたサポート提供を検討する必要があります。

Closing

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

この移行について開発者が理解しやすくなることを意図し、このドキュメントでは生きた情報を紹介しています。 所属する組織、お客様、IT 担当者、ハードウェア ベンダーとの話し合いを開始し、大容量セクターへの移行と、それが重要なシナリオにどのように影響するかについて協議してください。