Wie gefährlich ist das Senden von SIGINT an resize2fs, das mit der Verkleinerung beauftragt ist?

Wie gefährlich ist das Senden von SIGINT an resize2fs, das mit der Verkleinerung beauftragt ist?

Ich habe einen alten PC-Server (Quad Pentium 4) geerbt, der nur Partitionen für und /hatte (RAID1 mit 2 1T SATA-Festplatten), musste aber die Distribution aktualisieren (von CentOS 6.9). Ich habe beschlossen, eine neue Partition zu erstellen, damit die Partition mit formatiert werden konnte./bootswap/

-pAber ich habe vergessen, das Flag hinzuzufügen resize2fs, und jetzt starrt es mich still an und ich kann nicht sagen, wie lange es noch dauern könnte (es ist seit über 50 Stunden dabei). Jetzt weiß ich, dass das Verkleinern eines Dateisystemskann lange dauern, aber während ich warten konnte100 Stunden, etwas wie800 Stunden kommen nicht in Frage.

Folgendes denke ich im Moment:

  • Fahren Sie mit Ctrl+ C&& fort e2fsck.
  • Mounten Sie die Partition und löschen Sie manuell über 100 GB an Daten, die für uns keinen Zweck erfüllen.
  • Beginnen Sie von oben mitresize2fs -p ...

Aber ich konnte nicht findenKonsensdarüber, wiegefährliches soll SIGINT an gesendet werden resize2fs.

Ich habe zwar ein zusätzliches Backup der wichtigen Informationen, möchte dies aber trotzdem tun, ohne das Dateisystem zu beschädigen. Und ja, ich bin mir bewusst, dass es schneller sein könnte, die Distribution einfach von Grund auf neu zu installieren und mein Backup wiederherzustellen.

Aktualisieren: Ich habe beschlossen, es zu unterbrechen. Und alles scheint in Ordnung zu sein, aber die Frage bleibt bestehen. Ich bin immer noch neugierig.

Antwort1

Auf jeden Fall eine interessante Frage und während Ihr Ergebnis ziemlich gut war (und wie ich es gehofft hatte, da das Aufspüren SIGINTnicht gerade eine Raketenwissenschaft ist und ein Anhalten auf halbem Weg, bei dem lediglich einige Datenblöcke verschoben werden, auch nicht schwer zu sein scheint), gibt es auch genügend Geschichten von Misserfolgen, wie zum Beispiel 10yo Debian bughttps://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574292

Aber obwohl dieser Fehler 10 Jahre alt ist, habe ich gerade einen Mock- e2fsckund resize2fseinen Durchgang ausgeführt strace, und obwohl ersterer eine ganze Reihe von Signalhandlern installiert, darunter SIGINTund SIGTERM, resize2fstut er dies immer noch nicht.

Wenn also jemand diese Frage findet: Betrachten Sie das oben Gesagte als anekdotischen Beweis und bleiben Sie weiterhin vorsichtig. :-) Beachten Sie, dass auf der Manpage ein Flag zum Erstellen einer Undo-Datei im Falle von Fehlern erwähnt wird.

(Und ich wünschte nur, ich hätte diesen Größenänderungsvorgang innerhalb einer Bildschirmsitzung ausgeführt … aber ok, zumindest habe ich das getan -p)

bearbeiten

Moment, mir ist gerade eingefallen, warum nicht per SSH einloggen, einen LVM-Snapshot erstellen und e2fsckdas, während die Größenänderung noch läuft? Ich habe das während der Phase „Blöcke verschieben“ fünfmal hintereinander gemacht und obwohl ich bei jeder Prüfung die Meldung „enthält ein Dateisystem mit Fehlern, Prüfung erzwungen“ bekomme, wurden nie Fehler gefunden. Jetzt fragen Sie mich natürlich nicht nach der Datenintegrität.

bearbeiten

Ziemlich interessante Antwort von tytso@ selbst übrigens beihttps://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574292#30

verwandte Informationen