Wir, äh, hatten da eine kleine Dienstunterbrechung.
Wir legen jeden Tag einen Snapshot an, der weggesichert wird. Eigentlich sollten diese Snapshots rotiert und ausgedünnt werden. Wegen eines Tippfehlers im veranwortlichen Skript passierte das nicht. Heute Nacht ist dann die root-Partition vollgelaufen. Heute morgen war die erste Gegenmaßnahme alle alten Snapshots manuell zu löschen - und zwar mit einzelnen Aufrufen von btrfs subvolume delete... in einer for-Schleife aus der shell - was dazu führte, dass alle deletes gleichzeitig starteten. Dann fiel auf, dass nicht sofort Platz frei wurde. "Ha, naja, wird wohl dran liegen dass wir Scheissbalancing zwischen Daten und Metadatenblöcken haben, mach'mer mal ein balancing drauf" - Aber: btrfs führt das Löschen von subvolumes standardmäßig mit geringer I/O-Priorität aus. Ich hätte einfach warten müssen. Stattdessen hatte ich den neunzig wartenden deletes noch ein balancing hinzugefügt was quasi einmal alle Daten in die Hand nimmt und neu schreibt. The I/O subsystem came to a screeching halt. Dank des balancing vs. neunzig delete threads konnte der Kernel deadlocks beim flushen nicht mehr rechtzeitig auflösen und fing dann an, threads die mehr als 120 Sekunden auf I/O gewartet hatten zu killen. Das war dann der Punkt, wo die Maschine gegen 8:30 etwas unresponsiv wurde. Das war dann auch der Punkt, wo ich anfing, nicht mehr ganz so zuversichtlich bezüglich der schnellen Lösung des Problems zu sein. Klar, ich hätte einfach alles wegwerfen und das letzte Backup einspielen können, aber dann wäre die gesamte Arbeit von Artur und mir am Vorabend weggewesen. Das dumme ist, laufende deletes und balancings sind hart im Dateisystem gespeichert. Nach einem Kaltstart machte das Mistding dann genau da weiter wo es aufgehört hatte und rannte nach 20 Sekunden wieder in die io-subsystem-deadlock-Falle. Okay, Zeit ein rescue-system zu booten. Das war dann der Zeitpunkt an dem ist herausgefunden habe, dass das iDRAC5 mit Java 8 keine Medien mehr remote einhängen kann. Also bin ich da gegen 16:00 früher abgehauen, bin zu VegaSystems gefahren, hab das Ding lokal vom Stick gebootet, hab dem btrfs offline alle subvolumes gelöscht, hab alle aktuellen Daten mit rsync nach Bielefeld gesichert (das ging noch! fucking rocksolid was die Datenintegrität angeht), das btrfs neu angelegt und alles zurückkopiert. So, und hier sind mer jetzt.
Also: Don't root before coffee, egal wie scheisse es aussieht. And: Know your fucking filesystems in and out, if you plan to do fancy stuff. If you feel that you know it, you probably don't. Doesn't hurt to read a technical paper once in a while.
Wir legen jeden Tag einen Snapshot an, der weggesichert wird. Eigentlich sollten diese Snapshots rotiert und ausgedünnt werden. Wegen eines Tippfehlers im veranwortlichen Skript passierte das nicht. Heute Nacht ist dann die root-Partition vollgelaufen. Heute morgen war die erste Gegenmaßnahme alle alten Snapshots manuell zu löschen - und zwar mit einzelnen Aufrufen von btrfs subvolume delete... in einer for-Schleife aus der shell - was dazu führte, dass alle deletes gleichzeitig starteten. Dann fiel auf, dass nicht sofort Platz frei wurde. "Ha, naja, wird wohl dran liegen dass wir Scheissbalancing zwischen Daten und Metadatenblöcken haben, mach'mer mal ein balancing drauf" - Aber: btrfs führt das Löschen von subvolumes standardmäßig mit geringer I/O-Priorität aus. Ich hätte einfach warten müssen. Stattdessen hatte ich den neunzig wartenden deletes noch ein balancing hinzugefügt was quasi einmal alle Daten in die Hand nimmt und neu schreibt. The I/O subsystem came to a screeching halt. Dank des balancing vs. neunzig delete threads konnte der Kernel deadlocks beim flushen nicht mehr rechtzeitig auflösen und fing dann an, threads die mehr als 120 Sekunden auf I/O gewartet hatten zu killen. Das war dann der Punkt, wo die Maschine gegen 8:30 etwas unresponsiv wurde. Das war dann auch der Punkt, wo ich anfing, nicht mehr ganz so zuversichtlich bezüglich der schnellen Lösung des Problems zu sein. Klar, ich hätte einfach alles wegwerfen und das letzte Backup einspielen können, aber dann wäre die gesamte Arbeit von Artur und mir am Vorabend weggewesen. Das dumme ist, laufende deletes und balancings sind hart im Dateisystem gespeichert. Nach einem Kaltstart machte das Mistding dann genau da weiter wo es aufgehört hatte und rannte nach 20 Sekunden wieder in die io-subsystem-deadlock-Falle. Okay, Zeit ein rescue-system zu booten. Das war dann der Zeitpunkt an dem ist herausgefunden habe, dass das iDRAC5 mit Java 8 keine Medien mehr remote einhängen kann. Also bin ich da gegen 16:00 früher abgehauen, bin zu VegaSystems gefahren, hab das Ding lokal vom Stick gebootet, hab dem btrfs offline alle subvolumes gelöscht, hab alle aktuellen Daten mit rsync nach Bielefeld gesichert (das ging noch! fucking rocksolid was die Datenintegrität angeht), das btrfs neu angelegt und alles zurückkopiert. So, und hier sind mer jetzt.
Also: Don't root before coffee, egal wie scheisse es aussieht. And: Know your fucking filesystems in and out, if you plan to do fancy stuff. If you feel that you know it, you probably don't. Doesn't hurt to read a technical paper once in a while.
Aucun commentaire:
Enregistrer un commentaire