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

Discussion in 'Proxmox VE (Deutsch)' started by fpausp, Jan 12, 2018.

  1. fpausp

    fpausp Member

    Joined:
    Aug 31, 2010
    Messages:
    190
    Likes Received:
    2
    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...
     
  2. dcsapak

    dcsapak Proxmox Staff Member
    Staff Member

    Joined:
    Feb 1, 2016
    Messages:
    2,237
    Likes Received:
    194
    der output von
    Code:
    lvs
    vgs
    
    wäre interessant
    prinzipiell infos zu lvm thin gibts unter

    Code:
    man lvmthin
    
    besonders der teil: 'metadata check and repair'
     
  3. fireon

    fireon Well-Known Member
    Proxmox VE Subscriber

    Joined:
    Oct 25, 2010
    Messages:
    2,509
    Likes Received:
    127
    @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.
     
  4. dcsapak

    dcsapak Proxmox Staff Member
    Staff Member

    Joined:
    Feb 1, 2016
    Messages:
    2,237
    Likes Received:
    194
    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

    ohne mehr infos schwer zu sagen
     
  5. fpausp

    fpausp Member

    Joined:
    Aug 31, 2010
    Messages:
    190
    Likes Received:
    2
    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...
     
  6. fireon

    fireon Well-Known Member
    Proxmox VE Subscriber

    Joined:
    Oct 25, 2010
    Messages:
    2,509
    Likes Received:
    127
    Ja das wäre spannend.
     
  7. derDymo

    derDymo New Member

    Joined:
    Jun 3, 2018
    Messages:
    1
    Likes Received:
    1
    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
     
    fireon likes this.
  8. wbumiller

    wbumiller Proxmox Staff Member
    Staff Member

    Joined:
    Jun 23, 2015
    Messages:
    573
    Likes Received:
    65
    Prinzipiell kann man das schon machen, muss aber explizit auch die metadaten volume mitvergrößern. Das passiert leider nicht automatisch.
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice