SSD, Erase Block Size & LVM: PV auf Raw Device, Alignment

Ich möchte eine neue SSD installieren und das gesamte Gerät als PV für LVM verwenden - mit anderen Worten: Ich plane nicht, auch nur eine Partition auf dieses Gerät zu setzen. Das Ausrichten von Partitionen auf den Löschblöcken ist nicht erforderlich.

Fragen)

Ist es ausreichend, --dataalignmentbeim Löschen die Blockgröße pvcreateund --physicalextentsizebeim Löschen ein Vielfaches der Blockgröße vgcreateeinzustellen?

Unter der Annahme, dass meine SSD eine Löschblockgröße von 1024 KB hat, ist dies in Ordnung

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

Sonst noch etwas zu beachten?

Angenommen, ich würde ext4-Dateisysteme auf den LVs in dieser VG platzieren, wäre es eine gute Idee, die ext4-Extents an der LVM-PE-Größe auszurichten, oder? Ext4-Extents sollten also die gleiche Größe wie LVM-PE oder ein Vielfaches davon haben?

Vielen Dank für jede Klarstellung!

Ja, ich habe auch das gesamte Festplattenlayout von MBR / PBR / GPT / MD / LVM überprüft und bin zu demselben Ergebnis gekommen.

Wenn in Ihrem Fall (LVM auf Raw-Festplatte) LVM-PE (physischer Umfang) mit pvcreate auf 1 MB ausgerichtet ist, können Sie sicher sein, dass alle weiteren Datenzuordnungen ausgerichtet werden, solange Sie die Zuordnungsgröße auf (1 MB * N) beibehalten. .

Da sowohl "vgcreate -s" als auch "lvcreate -L" standardmäßig "size-without-unit" als MB-Wert behandeln, müssen Sie sich wahrscheinlich nicht mehr um die Ausrichtung kümmern, wenn Sie pvcreate ordnungsgemäß ausgeführt haben. Stellen Sie nur sicher, dass Sie die Größe nicht in% / PEs (für lvcreate -l) und B (Byte) / S (512B - Sektor ist immer 512B in LVM) / K (KB) (für vgcreate -s und lvcreate -L) angeben.

=== zur Verdeutlichung hinzugefügt ===

Während eine SSD möglicherweise eine Löschblockgröße von 1024 KB als Ganzes hat, liegt die Löschblockgröße / RW-Seitengröße jedes internen Flash-Chips wahrscheinlich bei 32 KB - 128 KB / 512 KB - 8 KB.

Obwohl dies von der Steuerung der einzelnen SSDs abhängt, wird die E / A-Beeinträchtigung aufgrund eines zusätzlichen Lese-, Änderungs- und Schreibzyklus wahrscheinlich nicht eintreten, solange Sie den Schreibvorgang so ausrichten, dass die Blockgröße jedes internen Chips (32 bis 128 KB) oben gelöscht wird Beispiel. Sie möchten nur, dass eine einzelne Schreibanforderung groß genug ist (= Blockgröße der SSD als Ganzes löschen), sodass Sie eine bessere Leistung erwarten können, indem Sie alle internen Chips / Kanäle effizient steuern.

Ich verstehe, dass 1024 KB-Ausrichtung nur eine Sicherheitsmaßnahme ist, da die Funktion des Controller-Chips von Hersteller zu Hersteller unterschiedlich ist und sich die Spezifikation des Flash-Chips schnell ändert. Es ist wichtiger, dass die Schreibanforderung auf Betriebssystemebene in einem großen Bündel (in diesem Fall 1024 KB) ausgeführt wird.

Wenn Sie nun mkfs (8) für einen mit 1 MB ausgerichteten LVM-Block ausführen, wird die 1 MB-Ausrichtung für Daten / Metadaten auf Dateisystemebene mit ziemlicher Sicherheit unterbrochen. Die meisten Dateisysteme sind nur für die 4-KB-Ausrichtung zuständig, daher ist es wahrscheinlich nicht perfekt für SSDs (aber, IIRC, aktuelle fs wie btrfs versuchen, die Ausrichtung von 64 KB + beizubehalten, wenn interne zusammenhängende Blöcke zugewiesen werden). Viele fs verfügen jedoch über eine Funktion zum Bündeln von Schreibvorgängen (z. B. Konfiguration in Stripe-Größe), um die Leistung von RAID zu optimieren, sodass Schreibanforderungen an SSD nahezu optimal ausgeführt werden können.

Ich möchte meine Aussage wirklich mit tatsächlichen Daten untermauern, aber es war wirklich schwierig zu beweisen, da der heutige SSD-Controller so intelligent ist und keine großen Leistungseinbußen aufweist, wenn sowohl die Ausrichtungs- als auch die Schreibgröße "groß genug" sind. Stellen Sie nur sicher, dass es nicht schlecht ausgerichtet ist (<4KB-Aligment um jeden Preis vermeiden) und nicht zu klein (1024KB ist groß genug).

Wenn Sie sich wirklich für die E / A-Strafe interessieren, überprüfen Sie dies noch einmal, indem Sie den Gerätecache deaktivieren und das Benchmarking mit dem synchronisierten Lese-, Schreib- und Überschreibungstest durchführen.

Nach meinem Verständnis sind die Standardeinstellungen bereits gut genug. Ich glaube nicht, dass Sie sich um die Option --dataalignment kümmern müssen, da LVM automatisch versucht, alles basierend auf den von sysfs exportierten Werten auszurichten. Weitere Informationen finden Sie in der Option "data_alignment_detection" in der Datei lvm.conf:

# 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

Darüber hinaus ist es nicht erforderlich, eine physische Größe für vgcreate anzugeben, da die Standardgröße bereits 4 MB beträgt.