Die Symptome passen ziemlich gut zu einem vollgelaufenen thin-pool: sobald
data (oder die metadata) mal auf 100% geht, kippt LVM das thin-volume in einen Fehlerzustand und dann scheitert der pre-start-Hook genau so mit status 32. Dass es jetzt wieder läuft nachdem du aufgeräumt hast, würde da auch reinpassen.
Das Dilemma mit dem aktuellen
df/
lvs ist halt: nach dem Aufräumen siehst du den vollen Pool nicht mehr, deswegen ist Impacts Frage nach dem Beweis berechtigt. Der steckt aber in den alten Logs. Schau mal ob du im journal/dmesg noch Meldungen von damals findest:
Code:
journalctl -k | grep -i thin
dmesg | grep -i thin
Wenn der Pool vollgelaufen war, stehen da Zeilen wie "thin pool pve-data-tpool ... reached 100% of its data space". Das wäre dann der handfeste Beleg. Falls das journal schon rotiert ist, mal in
/var/log/syslog* gegenchecken.
Wenn sichs bestätigt, zwei Wege: entweder wie TErxleben sagt nicht mehr überprovisionieren (am saubersten), oder dem thin-pool autoextend + Monitoring verpassen (
thin_pool_autoextend_threshold in der lvm.conf + dmeventd läuft), dann wächst er automatisch bevor er 100% trifft statt dir die Container abzuschießen. Und die metadata nicht vergessen, die läuft gern unbemerkt voll und legt den Pool genauso lahm.
