web-dev-qa-db-ja.com

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

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

質問

_--dataalignment_をpvcreateingの消去ブロックサイズに設定し、_--physicalextentsize_をvgcreateingの消去ブロックサイズの倍数に設定するだけで十分ですか？

したがって、私のSSDの消去ブロックサイズが1024kであると仮定すると、

  • _pvcreate --dataalignment 1024k /dev/ssd_
  • vgcreate --physicalextentsize $(( x * 1024 ))k ...

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

このVGのLVにext4-filesystemsを配置すると仮定すると、ext4-extentsをLVM-PEサイズに揃えることは良い考えでしょうか？それで、ext4-extentsはLVM-PE-sizeと同じサイズか倍数にする必要がありますか？

説明をありがとう！

lvmssdalignment
15
m.sr

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

あなたのケース（生ディスク上のLVM）では、LVM-PE（物理エクステント）がpvcreateで1MB整列されている場合、割り当てサイズを（1MB * N）に保つ限り、すべてのさらなるデータ割り当てが確実に整列されます。 。

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

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

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

これは各SSDのコントローラーに依存しますが、上記の32KB〜128KBの各内部チップの消去ブロックサイズに書き込みを合わせ続ける限り、追加の読み取り/変更/書き込みサイクルによる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ペナルティに本当に関心がある場合は、デバイスキャッシュを無効にして再確認し、同期された読み取り/書き込み/書き換えテストでベンチマークを行ってください。

9
Taisuke Yamada

私の理解では、デフォルトはすでに十分です。 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を指定する必要はありません。

6
Kereoz