OSでアドレス指定可能なディスクサイズ
3ware9550SXU-12ストレージコントローラーと750Gディスクが接続されています。ディスクは単一ユニットとして構成されます（JBODではありません）。
主に、パーティションの配置、暗号化、RAIDレベルなどが読み取り/書き込み/ IOPSのパフォーマンスに与える影響を確認するために、いくつかのパフォーマンステストを実行しています。
私の場合、同じストレージ構成の読み取り/書き込みパフォーマンスが、整列されていないパーティションよりも整列されたパーティションの方がわずかに低いことに驚きました。
これにより、3wareコントローラーを介して接続した場合と、RAIDサポートがまったく付属していないマザーボードのポートを使用した場合のOSからのディスクの表示方法に違いがあるかどうかを確認するようになりました。
構成データがディスク上のDCBブロックから読み取られるときに、コントローラーを再構成せずにコントローラーを交換できるようにするために、3wareコントローラーがディスクに配置するディスク制御ブロック（DCB）メタデータについて知っています。私のコントローラーは「新しいフォーマット」を使用しています。これは、コントローラーがディスクの最後の1024LBAにDCBを書き込むことを意味しているようです。
ディスクの一部のみをOSに提示する3wareコントローラーによって、調整作業が失敗していないかどうかを確認することに興味がありました。
私が見つけたもの：
- 3wareコントローラーの有無にかかわらず、ディスクの先頭はまったく同じように見えます。ここでの配置に影響はないはずです。 dd/md5sumで検証済み。
- ディスクの最後の1024 * 512Bには、実際に3wareによってそこに配置されているように見えるものが含まれています（そこにある読み取り可能な文字列から判断すると）
- ここで興味深い部分は、3wareの制御下にある場合、ディスクは749988741120 Bのメディアサイズを報告し、直接接続されている場合は750156374016 Bです。つまり、3wareコントローラーを介して接続されている場合、OSは約160MB少ないディスクメディアにアクセスできます。
1024x512B（DCB）の違いだけであれば理解できますが、160MBは、このタイプのコントローラーメタデータを格納するには少し多すぎるようです。
質問：
ユニット構成をそれらのディスクに保存するコントローラーに接続されたディスク上のパーティションを整列するときに、私が見逃したかもしれない他の考慮事項があるかどうか誰かが知っていますか？
好奇心から-最後の160MBのディスクメディアが何に使用されているか知っている人はいますか？
ありがとう
3wareに慣れていないので、直接コメントすることはできません。
ただし、一般的に、ディスクスペースを「盗む」かなりの数のストレージアレイに遭遇しました。次のようなさまざまな理由があります。
- コントローラはカットダウンOSを実行し、スペースが必要です。 （構成/管理など）
- コントローラは書き込みキャッシュを実行し、電源障害が発生した場合、キャッシュを緊急フラッシュするためにどこかが必要になります。
- サイズの正規化。ディスクサイズのわずかな変動を許容します。
- コントローラに組み込まれている「アロケーションユニット」。固定倍数の割り当てのみを許可します。 （通常、キャッシュ/ページングの制限に対応しています）。
アラインメントに関して-正しいアラインメントが遅くなると私が考えることができる唯一の理由は、コントローラーがまたアラインメントを処理している場合です。アレイ/コントローラーはますますホストOSに対応しています。これは、SCSIフラグを正しく設定する必要があるためですが、この配置の問題も原因です。
アレイがホストのプラットフォームを認識している場合は、すでに内部でアライメントが「調整」されていることに気付くかもしれません。 （したがって、自分自身を整列させることによって、あなたはそれを再び整列させませんでした）。