SSD、消去ブロックサイズとLVM：rawデバイスのPV、アライメント

新しいSSDをインストールし、デバイス全体をLVMのPVとして使用します。つまり、このデバイスにパーティションを1つも配置する予定はありません。そのため、消去ブロックでパーティションを揃える必要はありません。

質問

ingの--dataalignment場合は消去ブロックサイズに設定し、pvcreateingの場合は消去ブロックサイズ--physicalextentsizeの倍数に設定するだけで十分vgcreateですか？

だから、私のSSDが1024kの消去ブロックサイズを持っていると仮定すると、それは大丈夫ですか？

• pvcreate --dataalignment 1024k /dev/ssd
• vgcreate --physicalextentsize $(( x * 1024 ))k ...

他に考慮すべきことはありますか？

このVGのLVにext4-filesystemsを配置すると仮定すると、ext4-extentsをLVM-PE-sizeに揃えることをお勧めしますか？ext4-extentsはLVM-PE-sizeと同じサイズまたは複数のサイズにする必要がありますか？

明確化をありがとう！

はい、MBR / PBR / GPT / MD / LVMのすべてのディスク上のレイアウトもチェックアウトし、同じ結論に達しました。

あなたの場合（rawディスク上のLVM）、LVM-PE（物理エクステント）がpvcreateで1MBにアラインされている場合、割り当てサイズを（1MB * N）に保つ限り、すべてのデータアロケーションがアラインされることを確認できます。

「vgcreate -s」と「lvcreate -L」はどちらもデフォルトでMBとしてサイズなしの単位を処理するため、pvcreateを適切に行った後は、おそらくアライメントを気にする必要はありません。サイズを％/ PEs（lvcreate -lの場合）およびB（byte）/ S（512B-セクターは常にLVMの512B）/ K（KB）（vgcreate -sおよびlvcreate -Lの場合）で指定しないようにしてください。

===明確化のために追加===

フォローアップとして、SSDはデバイス全体として1024KBの消去ブロックサイズを持っているかもしれませんが、各内部フラッシュチップの消去ブロックサイズ/ rwページサイズはおそらく約32KB-128KB / 512B-8KBです。

これは各SSDのコントローラーに依存しますが、各内部チップのブロックサイズを消去するように書き込みを調整している限り、余分な読み取り-変更-書き込みサイクルによるI / Oペナルティはおそらく発生しません。例。単一の書き込み要求が十分な大きさ（=デバイス全体としてのSSDの消去ブロックサイズ）になるようにしたいので、すべての内部チップ/チャネルを効率的に駆動することにより、より良いパフォーマンスを期待できます。

私の理解では、コントローラチップの機能はベンダーによって異なり、フラッシュチップの仕様は急速に変化するため、1024KBのアライメントは安全対策にすぎません。OSレベルの書き込み要求を大きなバンドル（この場合は1024KB）で行うことがより重要です。

さて、1MBにアライメントされたLVMブロックでmkfs（8）を実行すると、ファイルシステムレベルのデータ/メタデータの1MBアライメントがほぼ確実に壊れます。ほとんどのファイルシステムは4KBアライメントのみを行うため、SSDにはおそらく完璧ではありません（しかし、IIRC、btrfsのような最近のfsは、内部連続ブロックを割り当てるときに64KB +アライメントを維持しようとします）。ただし、多くのfsには書き込みをバンドルする機能（例：ストライプサイズ構成）があり、RAIDからパフォーマンスを引き出すため、SSDへの書き込み要求を最適に近いものにするために使用できます。

実際のデータでステートメントをバックアップしたいのですが、今日のSSDコントローラーは非常にインテリジェントであり、アライメントサイズと書き込みサイズの両方が「十分に大きい」場合、パフォーマンスの低下はあまり見られないため、証明するのは本当に困難でした。正しく調整されていないこと（すべてのコストで<4KB-aligmentを避けていること）および小さすぎないことを確認してください（1024KBで十分です）。

また、IOのペナルティが本当に重要な場合は、デバイスキャッシュを無効にし、同期化された読み取り/書き込み/再書き込みテストでベンチマークを実行して、二重チェックを行います。

私の理解では、デフォルトはすでに十分です。LVMはsysfsのエクスポート値に基づいてすべてを自動的に調整しようとするため、--dataalignmentオプションについて心配する必要はないと思います。lvm.confの「data_alignment_detection」オプションを参照してください。

# By default, the start of a PV's data area will be a multiple of
# the 'minimum_io_size' or 'optimal_io_size' exposed in sysfs.
# - minimum_io_size - the smallest request the device can perform
#   w/o incurring a read-modify-write penalty (e.g. MD's chunk size)
# - optimal_io_size - the device's preferred unit of receiving I/O
#   (e.g. MD's stripe width)
# minimum_io_size is used if optimal_io_size is undefined (0).
# If md_chunk_alignment is enabled, that detects the optimal_io_size.
# This setting takes precedence over md_chunk_alignment.
# 1 enables; 0 disables.
data_alignment_detection = 1

さらに、デフォルトはすでに4MBであるため、vgcreateにphysicalextentsizeを指定する必要はありません。