Thin's thin-pool needs inspection. - ???

[fpausp]

Kann mir bitte jemand einen Tipp geben was der wahrscheinlichste Grund sein könnte und wie man den thin-pool inspiziert ?

root@pve01:~# qm start 112
WARNING: /dev/bigdisk/vm-107-disk-1: Thin's thin-pool needs inspection.
WARNING: /dev/bigdisk/vm-601-disk-1: Thin's thin-pool needs inspection.
WARNING: /dev/bigdisk/vm-601-disk-2: Thin's thin-pool needs inspection.
WARNING: /dev/bigdisk/vm-601-disk-3: Thin's thin-pool needs inspection.
WARNING: /dev/bigdisk/vm-601-disk-4: Thin's thin-pool needs inspection.
WARNING: /dev/bigdisk/vm-601-disk-5: Thin's thin-pool needs inspection.
WARNING: /dev/bigdisk/vm-114-disk-1: Thin's thin-pool needs inspection.
WARNING: /dev/bigdisk/vm-115-disk-2: Thin's thin-pool needs inspection.
WARNING: /dev/bigdisk/vm-115-disk-1: Thin's thin-pool needs inspection.
WARNING: /dev/bigdisk/vm-115-disk-3: Thin's thin-pool needs inspection.
WARNING: /dev/bigdisk/vm-999-disk-1: Thin's thin-pool needs inspection.
WARNING: /dev/bigdisk/vm-703-disk-1: Thin's thin-pool needs inspection.
WARNING: /dev/bigdisk/vm-108-disk-1: Thin's thin-pool needs inspection.
WARNING: /dev/bigdisk/vm-109-disk-1: Thin's thin-pool needs inspection.
WARNING: /dev/bigdisk/vm-106-disk-1: Thin's thin-pool needs inspection.
WARNING: /dev/bigdisk/vm-777-disk-1: Thin's thin-pool needs inspection.
WARNING: /dev/bigdisk/vm-777-disk-2: Thin's thin-pool needs inspection.
WARNING: /dev/bigdisk/vm-777-disk-3: Thin's thin-pool needs inspection.
WARNING: /dev/bigdisk/vm-777-disk-4: Thin's thin-pool needs inspection.
WARNING: /dev/bigdisk/vm-777-disk-5: Thin's thin-pool needs inspection.
WARNING: /dev/bigdisk/vm-888-disk-1: Thin's thin-pool needs inspection.
WARNING: /dev/bigdisk/vm-110-disk-1: Thin's thin-pool needs inspection.
WARNING: /dev/bigdisk/vm-513-disk-1: Thin's thin-pool needs inspection.
WARNING: /dev/bigdisk/vm-514-disk-1: Thin's thin-pool needs inspection.
WARNING: /dev/bigdisk/vm-111-disk-1: Thin's thin-pool needs inspection.
WARNING: /dev/bigdisk/vm-111-disk-2: Thin's thin-pool needs inspection.
WARNING: /dev/bigdisk/vm-667-disk-1: Thin's thin-pool needs inspection.
WARNING: /dev/bigdisk/vm-112-disk-1: Thin's thin-pool needs inspection.
WARNING: /dev/bigdisk/vm-112-disk-2: Thin's thin-pool needs inspection.

Die 112er startet auch nicht richtig...

 

[dcsapak]

der output von

lvs
vgs

wäre interessant
prinzipiell infos zu lvm thin gibts unter

man lvmthin

besonders der teil: 'metadata check and repair'

 

[fireon]

@dcsapak Sag mal schickt der Server bei solchen Fehlern eigentlich ein Mail aus? Wenn bei ZFS da was nicht passt wird sofort drauf aufmerksam gemacht. Oder seh ich den Fehler jetzt als zu kritisch. Hab das so noch nie gesehen.

 

[dcsapak]

Sag mal schickt der Server bei solchen Fehlern eigentlich ein Mail aus? Wenn bei ZFS da was nicht passt wird sofort drauf aufmerksam gemacht.

soweit ich weiß nicht, bei zfs gibts aber den zed und für smart den smartd, wüsste nicht dass es bei lvm so einen daemon gibt

Oder seh ich den Fehler jetzt als zu kritisch. Hab das so noch nie gesehen.

ohne mehr infos schwer zu sagen

 

[fpausp]

OK dcsapak, werd ich mir genauer ansehen. Ich wollte eine Softwareraidinstallation mit 4x4TB Platten simulieren.

Nach dem löschen dieser vm am Testserver scheint alles wieder normal zu funktionieren.

Vielleicht kann ich den Fehler reproduzieren...

 

[fireon]

Vielleicht kann ich den Fehler reproduzieren...

Ja das wäre spannend.

 

[derDymo]

Ein herzlich Hallo an alle!

Aus gegebenen Anlass bin ich hier auf diesen Thread gestolpert, da ich aktuell das selbe "Problem" habe. Sorry für das ausgraben dieses Posts, ich denke aber dass dieser Threat nach einem halben Jahr vielleicht noch nicht zu alt ist.

Als ich einen Mountpoint eines Containers in einen Thinpool kopieren wollte, sind mir diese Meldungen begegnet und dabei ist mir aufgefallen, dass in meinem Fall im ThinPool die Metadata voll gelaufen ist.

Als Hintergrund Info für Euch: Auf meiner VG "VG1" habe ich den Thinpool mit 100G größe erstellt und dann im Nachhinein den Thinpool um 900G erweitert. Bei einem Vergleich, in dem ich gleich ein 1000G großen Pool erstellt habe, war das Meta-Volume 128 MB anstelle der 52 MB groß. Das vergrößern eines Thinpools ist also offensichtlich mit Vorsicht zu genießen!
Ach ja, die betroffenen Maschinen sind Container, im Falle es eine Relevanz hat.

So, nun aber zu den Fakten:

root@svrspve1:~# lvs -a
WARNING: /dev/VG1/vm-101-disk-3: Thin's thin-pool needs inspection.
WARNING: /dev/VG1/vm-107-disk-3: Thin's thin-pool needs inspection.
WARNING: /dev/VG1/vm-106-disk-2: Thin's thin-pool needs inspection.
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
LV-vmdata VG1 twi-cotzM- 1.04t 9.02 99.61
[LV-vmdata_tdata] VG1 Twi-ao---- 1.04t
[LV-vmdata_tmeta] VG1 ewi-ao---- 52.00m
...

Beim Versuch den thin-pool zu reparieren bekam ich nun folgende Meldung:

root@svrspve1:~# lvconvert --repair /dev/VG1/LV-vmdata
WARNING: /dev/VG1/vm-101-disk-3: Thin's thin-pool needs inspection.
WARNING: /dev/VG1/vm-107-disk-3: Thin's thin-pool needs inspection.
WARNING: /dev/VG1/vm-106-disk-2: Thin's thin-pool needs inspection.
Using default stripesize 64.00 KiB.
Only inactive pool can be repaired.

Und nun soll ich also den Thinpool deaktivieren, was mir aktuell etwas schwerfällt, das deaktivieren nach klassischer Weise lvchange -an /dev/VG1/LV-vmdata deaktiviert die Meta- und Data-LV nicht. ich soll wohl jetzt den Server rebooten. Dieser reboot hat wie eigentlich erwartet
nichts gebracht, daher sah meine Lösung nun etwas anders aus, und ich hätte auch früher darauf kommen sollen:
Die betroffenen VMs müssen nicht nur heruntergefahren sein, es müssen die betroffnen LVs mit lvchange deaktiviert werden und danach kann der thinpool deaktiviert werden. Und siehe da, nun funktioniert auch der lvconvert --repair.

root@svrspve1:~# lvchange -an /dev/VG1/vm-101-disk-3
root@svrspve1:~# lvchange -an /dev/VG1/vm-106-disk-2
root@svrspve1:~# lvchange -an /dev/VG1/vm-107-disk-3
root@svrspve1:~# lvchange -an /dev/VG1/LV-vmdata
root@svrspve1:~# lvs -a
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
LV-vmdata VG1 twi---tz-- 1.04t
[LV-vmdata_tdata] VG1 Twi------- 1.04t
[LV-vmdata_tmeta] VG1 ewi------- 52.00m
LV-vmthin VG1 twi-aotz-- 80.00g 44.15 32.59
[LV-vmthin_tdata] VG1 Twi-ao---- 80.00g
[LV-vmthin_tmeta] VG1 ewi-ao---- 52.00m
LViso VG1 -wi-ao---- 50.00g
[lvol0_pmspare] VG1 ewi------- 52.00m
vm-101-disk-1 VG1 Vwi-a-tz-- 8.00g LV-vmthin 59.68
vm-101-disk-3 VG1 Vwi---tz-- 20.00g LV-vmdata
vm-102-disk-1 VG1 Vwi-aotz-- 2.00g LV-vmthin 53.56
vm-103-disk-1 VG1 Vwi-aotz-- 8.00g LV-vmthin 63.99
...

root@svrspve1:~# lvconvert --repair /dev/VG1/LV-vmdata
Using default stripesize 64.00 KiB.
WARNING: recovery of pools without pool metadata spare LV is not automated.
WARNING: If everything works, remove VG1/LV-vmdata_meta0 volume.
WARNING: Use pvmove command to move VG1/LV-vmdata_tmeta on the best fitting PV.

...zumindest ist er gewillt das zu tun. Repariert hatte er aber nicht wirkich. Daher geht es nochmal weiter:

root@svrspve1:~# lvextend /dev/VG1/LV-vmdata_tmeta -L 128m
Size of logical volume VG1/LV-vmdata_tmeta changed from 52.00 MiB (13 extents) to 128.00 MiB (32 extents).
Logical volume VG1/LV-vmdata_tmeta successfully resized.
root@svrspve1:~# lvconvert --repair /dev/VG1/LV-vmdata
Using default stripesize 64.00 KiB.
WARNING: recovery of pools without pool metadata spare LV is not automated.
WARNING: If everything works, remove VG1/LV-vmdata_meta2 volume.
WARNING: Use pvmove command to move VG1/LV-vmdata_tmeta on the best fitting PV.
root@svrspve1:~# lvchange -ay /dev/VG1/LV-vmdata
root@svrspve1:~# lvs -a
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
LV-vmdata VG1 twi-aotz-- 1.04t 0.79 6.66
LV-vmdata_meta0 VG1 -wi------- 52.00m
LV-vmdata_meta1 VG1 -wi------- 52.00m
LV-vmdata_meta2 VG1 -wi------- 128.00m
[LV-vmdata_tdata] VG1 Twi-ao---- 1.04t
[LV-vmdata_tmeta] VG1 ewi-ao---- 128.00m
LV-vmthin VG1 twi-aotz-- 80.00g 44.15 32.59
...

Nun sieht die Welt schon einiges besser aus. Ja, der --repair braucht natürlich auch etwas Platz. Wenn man also die Möglichkeit nicht von Anfang an verspielt hat, sollte man den meta Bereich vorher erweitern.
Nach dem aktivieren aller LVs, die ich zuvor deaktiviert habe, booten die Container wieder wie gewohnt. In wie weit mir nun ein Datenverlust auf den betroffnen LVs entstanden ist, kann ich aktuell noch nicht sagen, oberflächlich sah alles korrekt aus. Im Live-Betrieb würde ich nun auf das Backup vertrauen!

Mein Fazit aus dieser Lehr-Stunde:
Das ursprüngliche Problem bei mir war meine Naivität, zum einen einen kleinen Pool zu vergrößern um dann ein großes LV in den Pool zu kopieren. Mit der plötzlich hohen Datenmenge konnte wohl der LVM ThinPool nicht umgehen...
Um das nochmal genauer zu hinterfragen, sollte ich eigentlich diesen Vorgang nochmal wiederholen, allerdings mit einem ThinPool, der von Anfang an die korrekte Größe hat. Da ich mich aber kenne, vermute ich mal dass ich das zumindest nicht so schnell machen werde... Aber wenn, dann berichte ich das hier.
Vielleicht hätte in meinem Fall sogar gereicht, einfach das eine Volume, dass ich 'eh wegwerfen muss, einfach zu löschen, aber auch das wäre nochmal einen Test Wert. Ich denke aber auch dass es möglicherweise einen Bugreport an LVM wert wäre, allein schon da beim vergrößern des Thinpools die Meta nicht berücksichtigt wurde. Vielleicht hätte ich aber auch im Vorfeld mehr darüber lesen sollen, denn es gibt auch die Möglichkeit, dass LVM automatisch bei Bedarf die LVs vergrößern kann. Auch den Meta-Bereich des Thinpools.

Ich hoffe dass meine Erfahrung hier etwas helfen konnte, im Falle jemand (vielleicht auch ich selber...) auf so ein Problem stößt.

Einen angenehmen Sonntag wünsche ich.
-- Rainer

 

[wbumiller]

Das ursprüngliche Problem bei mir war meine Naivität, zum einen einen kleinen Pool zu vergrößern

Prinzipiell kann man das schon machen, muss aber explizit auch die metadaten volume mitvergrößern. Das passiert leider nicht automatisch.