Was ist lvmetad und warum sollte oder muss ich es verwenden?

28

Ich habe einen Gentoo-Server mit LVM, der auf einem RAID-Array läuft, das ich seit einigen Jahren verwende. Kürzlich habe ich LVM auf 2.02.109 aktualisiert (erinnere mich nicht, welche Version es vorher war) und während des Upgrades eine Nachricht erhalten:

* Make sure to enable lvmetad in /etc/lvm/lvm.conf if you want
* to enable lvm autoactivation and metadata caching.

Ich verstehe , dass ich es durch Einstellung aktivieren kann use_lvmetad = 1in /etc/lvm/lvm.conf.

Aber warum brauche ich so eine Funktion? Meines Wissens nach funktioniert es mit udev-Regeln, um den LVM-Status in einem Cache zu halten, sodass LVM-Tools keine Volumes scannen müssen, um diese Informationen zu erhalten. Ist es nur so, dass mein kleines Array von einer solchen Funktion nicht profitieren kann? Unter welchen Umständen möchte / muss ich es verwenden?

lvm

— Steve Kalemkiewicz
quelle

1

Beschreibung

Aus der Manpage von lvmetad :

lvmetad ist ein Metadaten-Caching-Daemon für LVM. Der Dämon empfängt Benachrichtigungen von udev-Regeln (die installiert sein müssen, damit LVM ordnungsgemäß funktioniert, wenn lvmetad verwendet wird). Durch diese Benachrichtigungen verfügt lvmetad über ein aktuelles und konsistentes Image der im System verfügbaren Volume-Gruppen. Standardmäßig wird lvmetad, auch wenn es ausgeführt wird, von LVM nicht verwendet. Siehe lvm.conf (5).

Ein genauerer Blick darauf verdient eine weitere Definition. Wikipedia besagt:

Ein Journal-Dateisystem ist ein Dateisystem, das die Änderungen protokolliert, die in einem Journal vorgenommen werden (normalerweise ein Umlaufprotokoll in einem bestimmten Bereich des Dateisystems), bevor sie in das Hauptdateisystem übernommen werden. Im Falle eines Systemabsturzes oder eines Stromausfalls können solche Dateisysteme schneller wieder online geschaltet werden und es ist weniger wahrscheinlich, dass sie beschädigt werden.

Argumentation

Ich werde nicht näher auf LVM eingehen, da das OP die Vorteile bereits versteht. Daher erkläre ich nur, warum Journaling hinzugefügt wurde. Ältere Versionen von LVM hatten keinen Journal-Daemon. Wenn das System abstürzt, kann nur das physische Volume (Festplatte) als Journal verwendet werden. Dies führt zu einem Problem, wenn sich das logische Volume über mehrere Bereiche in logischen Volume-Gruppen erstreckt, die mehrere physische Volumes umfassen.

Wenn eine halbe Journaltransaktion auf einem physischen Datenträger und die andere Hälfte auf einem anderen physischen Datenträger vorhanden ist, kann das Transaktionsjournal keine Änderungen an beiden physischen Datenträgern festschreiben, da die physischen Datenträger aufgrund der Transaktion nicht verstehen, dass sie Teil einer Datenträgergruppe sind Das Protokoll ist nur auf dem physischen Datenträger vorhanden.

Hier kommt der neue Daemon ins Spiel. Anstelle eines Journalprotokolls für jedes physische Volume kann LVM jetzt ein Journalprotokoll erstellen und einen Abschnitt in der Volume-Gruppe dafür erstellen, der nur für die Journalerstellung vorgesehen ist. Anschließend kann das gesamte Transaktionsprotokoll auf Volumengruppenebene gefunden und wiedergegeben werden.

— eyoung100
quelle

14

Ihre Antwort scheint darauf hinzudeuten, dass lvmetad dem Dateisystem, das darauf ausgeführt wird, einen Dienst zur Verfügung stellt, der es ihm ermöglicht, ordnungsgemäß zu protokollieren. Andere Quellen sagen jedoch nur, dass sie Informationen zum LVM-Layout für die Befehlszeilen-Tools des Befehls lvm zwischenspeichern. Wäre nett, deine Version mit einigen Quellen zu unterstützen.

— Pavel Šimerda

8

Ich muss @ PavelŠimerdas Skepsis wiedergeben. Das lvmetad-Handbuch sagt nichts über Journaling aus. Ganz zu schweigen davon, dass es ein Layering-Verstoß wäre, wenn LVM anfangen würde, journalgestützt zu werden (dh, es muss bekannt sein, welche Dateisysteme journalgestützt sind und welche nicht, und es muss bekannt sein, welches Dateisystem darüber liegt davon). Ich sehe auch keinen Grund, warum es ein Problem sein könnte, das Journal eines Dateisystems auf mehrere physische Volumes zu verteilen. Das passiert die ganze Zeit mit anderen Technologien wie RAID 0.

— Dan Moulding

29

Über diesen Link :

Normalerweise führt jeder LVM-Befehl einen Festplattenscan durch, um alle relevanten physischen Datenträger zu finden und Datenträgergruppen-Metadaten zu lesen. Wenn der Metadaten-Daemon jedoch ausgeführt und aktiviert wird, kann dieser kostspielige Scan übersprungen werden. Dies kann eine erhebliche Menge an E / A-Vorgängen einsparen und die für den Abschluss von LVM-Vorgängen erforderliche Zeit verkürzen, insbesondere auf Systemen mit vielen Festplatten.

Sie würden es also ausführen, um die Leistung des LVM-Managements und der Statusvorgänge zu steigern, und zwar auf Kosten der Startleistung und der erhöhten Komplexität. Je mehr Festplatten sich im System befinden, desto höher ist die Leistungssteigerung.

— Matthew Sharp
quelle