Linux LVM Mirror: SyncAction "idle" nach drive failure test?

Hallo,

ich mache gerade ein paar Tests mit Linux Servern, beispielsweise Strom- und Diskausfälle simulieren.
Ein System hat ein LVM und bootet daraus. Alle LVM LVs sind ge-mirror-t. Nun habe ich hart ausgeschaltet und testweise eins der beiden SSDs (eine NVMe) ausgebaut und neu gestartet. Das LVM hat gemeckert, dass ein PV fehlt, ja klar, das liegt ja auf meinem Schreibtisch. Das System lief aber. Damit war der Test für mich erfolgreich.

Nach dem Test hab ich die SSD wieder eingebaut und

lvs -a -o +raid_sync_action,raid_mismatch_count

ausgeführt. Zu meiner Überraschung war

Cpy%Sync 100.00

und

SyncAction idle

. Ich hätte erwartet, dass ein Sync forciert wird und es eine Weile dauert, bis es wieder in Sync ist (wie bei einem mdadm RAID1).

Ich habe ein check durchlaufen lassen

lvchange --syncaction check vg/lv

, das hat echt lange gedauert. Danach hatte ich immer noch

Mismatches 0

Ich habe schon gegoogelt, aber leider nichts passendes gefunden, daher dachte ich, fragste hier mal, vielleicht hat einer ein paar Links.

Meine Fragen:

Warum muss das LVM nicht syncen, wenn ein PV weg war? Der Inhalt des verbliebenen PVs ändert sich ja (schon allein, weil etwas in /var/log geschreiben wird) und damit müssten nach dem Einabuen beide PVs unterschiedlichen Inhalt haben.
Bei einem RAID1 "weiß" das System, welcher Spiegel weg war (über einen Zähler oder so) und in diesen wird geschrieben. Wie ist das bei LVM?
Das sync dauert sehr lange.
iotop
zeigt keine I/O Last,
dstat
zeigt so 200 MB pro SSD. Da scheint es ein I/O Limit zu geben (wie bei md ja auch). Kann ich das hochstellen, damit es schneller synct (und wenn ja: wie )?

Danke für eure Zeit!

root@node1:~# lvs -a -o +raid_sync_action,raid_mismatch_count
  LV                    VG  Attr       LSize    Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert SyncAction Mismatches
  data                  pve twi-a-tz-- <766.85g             0.00   0.24
  [data_tdata]          pve rwi-aor--- <766.85g                                    100.00           idle                0
  [data_tdata_rimage_0] pve iwi-aor--- <766.85g
  [data_tdata_rimage_1] pve iwi-aor--- <766.85g
  [data_tdata_rmeta_0]  pve ewi-aor---    4.00m
  [data_tdata_rmeta_1]  pve ewi-aor---    4.00m
  [data_tmeta]          pve ewi-aor---   <7.83g                                    100.00           idle                0
  [data_tmeta_rimage_0] pve iwi-aor---   <7.83g
  [data_tmeta_rimage_1] pve iwi-aor---   <7.83g
  [data_tmeta_rmeta_0]  pve ewi-aor---    4.00m
  [data_tmeta_rmeta_1]  pve ewi-aor---    4.00m
  [lvol0_pmspare]       pve ewi-------   <7.83g
  root                  pve rwi-aor---   96.00g                                    100.00           idle                0
  [root_rimage_0]       pve iwi-aor---   96.00g
  [root_rimage_1]       pve iwi-aor---   96.00g
  [root_rmeta_0]        pve ewi-aor---    4.00m
  [root_rmeta_1]        pve ewi-aor---    4.00m
  swap                  pve rwi-aor---   32.00g                                    100.00           idle                0
  [swap_rimage_0]       pve iwi-aor---   32.00g
  [swap_rimage_1]       pve iwi-aor---   32.00g
  [swap_rmeta_0]        pve ewi-aor---    4.00m
  [swap_rmeta_1]        pve ewi-aor---    4.00m
root@pve:~#

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 4375566525

Url: https://administrator.de/contentid/4375566525

Ausgedruckt am: 21.11.2024 um 17:11 Uhr

3 Kommentare

Neuester Kommentar

Antwort zu Frage 3:
Das Limit kann man einstellen über

lvchange --maxrecoveryrate 0 pv/lv

0 steht dabei für unbegrenzt.

Die MAN-Page sagt eigentlich schon alles
https://man7.org/linux/man-pages/man7/lvmraid.7.html
Anhand von Prüfsummen für Bereiche kann schnell festgestellt werden was auf der Platte synchronisiert werden muss und was nicht, deswegen ist kein vollständiger Sync notwenig wenn das Entfernte und wieder hinzugefügte Drive das gleiche bleibt, und das geht dann ziemlich schnell wenn zwischen Entfernen und Hinzufügen nicht viel Zeit liegt.

The RAID implementation keeps track of which parts of a RAID LV
are synchronized. When a RAID LV is first created and activated
the first synchronization is called initialization. A pointer
stored in the raid metadata keeps track of the initialization
process thus allowing it to be restarted after a deactivation of
the RaidLV or a crash. Any writes to the RaidLV dirties the
respective region of the write intent bitmap which allow for fast
recovery of the regions after a crash. Without this, the entire
LV would need to be synchronized every time it was activated.

Automatic synchronization happens when a RAID LV is activated,
but it is usually partial because the bitmaps reduce the areas
that are checked. A full sync becomes necessary when devices in
the RAID LV are replaced.

The synchronization status of a RAID LV is reported by the
following command, where "Cpy%Sync" = "100%" means sync is
complete

Ach so, Du meinst, das sync war so schnell, das es schon fertig war, als ich gleich nach dem Booten geguckt habe?
ja, das könnte natürlich sein, sind zwei SSD als PVs.
Interessant, dass ich so einen Riesenvorteil von LVM RAID1 nicht kannte. Dachte immer, ist im westlichen das gleiche wie mdadm RAID1 (teilt sich ja angeblich Teile in Kernel).

Danke!

gelöst Frage Linux Server

Mehr von drahtbruecke

Bandlaufwerk hängt am Linuxserverdrahtbruecke - 3 Kommentare

Große Dateien archivieren (Backupdateien mit cmd und robocopy)drahtbruecke - 3 Kommentare

Lets Encrypt tut mit Absicht nichts gegen Phisingdrahtbruecke - 40 Kommentare

Debian: grafische Systemeinstellungen über SSH?drahtbruecke - 2 Kommentare

Heiß diskutiert