fsck läuft seit mehr als 30 Tagen auf 30 TB ext4 Partition und kann nicht geladen werden

432
G Grosschmid

Gegeben eine 30-TB-Partition von Festplatten auf hw raid5. LVM ist an der Spitze und das Dateisystem ist ext4. (Es sind zu 99,9% Daten.) Ich wollte weitere 20 TB hinzufügen und die Größe der Partition und des Dateisystems ändern. Vor der Größenänderung bestand es darauf, FSCK zuerst auszuführen. Es läuft seit mehr als einer Woche, ich habe es abgebrochen, konnte die Partition jedoch nicht mounten. FSCK war zuerst erforderlich. Also habe ich wieder angefangen.

fsck.ext4 -v -C 0 /dev/vgname/lvname e2fsck 1.44.3 (10-July-2018) Superblock has an invalid journal (inode 8). Clear<y>? yes *** journal has been deleted ***  Resize inode not valid. Recreate<y>? yes

Und seit 31 Tagen vergangen sind, läuft es immer noch und beansprucht 1 CPU-Kern zu 100%.

Wenn ich es mit strace betrachte, sehe ich Folgendes :

strace -p 3174 strace: Process 3174 attached strace: [ Process PID=3174 runs in x32 mode. ] strace: [ Process PID=3174 runs in 64 bit mode. ] pread64(4, "\375\210\372\374\360\10\375=$\375\254\221\375\334\361\375l?\376?U\376\24?\376\27\351\375:\305\375\217"..., 4096, 2447145635840) = 4096 mremap(0x7fa5e3565000, 208764928, 208769024, MREMAP_MAYMOVE) = 0x7fa5e3565000 pread64(4, "\0\305\7\0\321\376\377q\367\377Q\364\377\371\361\377H\355\377\323\346\377\271\337\377\275\332\377J\326\377\16"..., 4096, 1724118507520) = 4096 pread64(4, "x\377\371p\377_b\377\177W\377\35[\377\223N\377\226[\377&h\377QS\377\203O\377sT\377"..., 4096, 3443764559872) = 4096 pread64(4, "\377\263\371\377\375\355\377\363\6\0\367\356\377\326\21\0\350\353\377?\30\0\242\345\377\375\26\0|\344\377D"..., 4096, 6956990242816) = 4096 pread64(4, "\0\3201\273\0\24)\273\0\34=\273\0\336/\273\0\316/\273\0\3167\273\0\220*\273\0\3569\273"..., 4096, 8609803698176) = 4096 pread64(4, "o\f\257\205\16\377=\20\367\270\21\376\312\22\252R\0234\227\23\242\303\23\234\343\23Z\376\23LI\24"..., 4096, 1755810463744) = 4096 mremap(0x7fa5e3565000, 208769024, 208773120, MREMAP_MAYMOVE) = 0x7fa5e3565000 pread64(4, "\22\0\\\2\0\347\352\377\347\303\377?\250\3776\224\377Ht\377\17W\377\245G\377\5G\377}[\377"..., 4096, 14672424988672) = 4096 mremap(0x7fa5e3565000, 208773120, 208777216, MREMAP_MAYMOVE) = 0x7fa5e3565000 pread64(4, "\255\2\202)#m\22\5N\244F\210\221\20+.\21\5\352\306\344\220\25\3567\250\16\323\2\247P\352"..., 4096, 16981972766720) = 4096 mremap(0x7fa5e3565000, 208777216, 208781312, MREMAP_MAYMOVE) = 0x7fa5e3565000 pread64(4, "M\0\205N\0KO\0\4P\0\221P\0)Q\0\336Q\0\204R\0SS\0\tT\0\371T\0"..., 4096, 833004105728) = 4096

Alle 30-60 Sekunden wird eine neue Linie produziert, also ziemlich selten. Kann mir jemand einen Hinweis geben, was los ist und soll ich warten oder was ist zu tun, um wieder auf die Daten zugreifen zu können?

6
Ich sehe, dass Sie "fsck.ext4" mit dem Argument "-C 0" ausgeführt haben, das einen Fortschrittsbalken erzeugen sollte. Wie weit war die Messlatte fortgeschritten, als Sie bemerkten, dass es lange dauerte? Hat sich die Bar danach weiter entwickelt? kasperd vor 5 Jahren 0
Danke, trotz der Flagge gab es keinerlei Fortschritt, deswegen war ich ziemlich fassungslos. G Grosschmid vor 5 Jahren 0
Klingt nach einem Fehler in `fsck.ext4`. kasperd vor 5 Jahren 0

2 Antworten auf die Frage

0
antony_sebastian

Bitte führen Sie die folgenden Schritte aus,

Trennen Sie zuerst die Festplatte ab.

umount / dev / disk

Linux verwaltet mehrere redundante Kopien des Superblocks in jedem Dateisystem. Wir können Daten mit redundanten Kopien von Superblock-Metadaten wiederherstellen.

dumpe2fs / dev / disk | grep Superblock

Es werden alternative Superblöcke gezeigt, die wir verwenden können.

fsck -y -b blockid / dev / disk

Wiederholen Sie den Schritt für alle beschädigten Superblöcke. dh ersetzen Sie die Superblöcke durch einen Backup-Superblock.

mounten Sie die Diskette und können sie wieder verwenden

Ist das deine eigene Website? Bitte beachten Sie, dass Sie dies explizit angeben müssen, siehe [Hilfe] (/ help / promotion). Glorfindel vor 5 Jahren 1
Danke für den Vorschlag! Ich beschloss, es auszuprobieren, mich auf dem Server einzuloggen und mit screen -r fortzufahren. Ich bekam ein paar Dutzend Fragen zu der Frage, was ich mit Ja beantwortete, und es war fertig. ERGEBNIS: Alle ~ 1250 Ordner haben ihren Namen verloren und wurden in "lost + found" verschoben. Die Verzeichnisse müssen erneut umbenannt werden, der Inhalt scheint jedoch erhalten geblieben zu sein. G Grosschmid vor 5 Jahren 0
@GGrosschmid Wenn Ihre Frage damit beantwortet wurde, klicken Sie auf das Häkchen neben der Antwort, um anzugeben, dass es das richtige ist, um Ihr Problem zu lösen. music2myear vor 5 Jahren 0
0
G Grosschmid

danke Ihnen allen für Vorschläge. Die Platte wurde bereits vor dem Ausführen von fsck abgemeldet. Nachdem ich den Antwortvorschlag von antony_sebastian erhalten hatte, loggte ich mich beim Server ein, um dies zu versuchen, setzte meinen Bildschirmbefehl fort und fsck wartete auf Eingaben. Überraschenderweise war die Verarbeitung der 30-TB-Platte nach 33 Tagen abgeschlossen. Als Antwort auf alle behebbaren Probleme wurden die Daten mit "Ja" beantwortet, obwohl alles unter "Lost + found" verschoben wurde und die Verzeichnisnamen der Stammverzeichnisstruktur verloren gingen. Abgesehen davon waren die Daten intakt und in Ordnung.

Danke für die Anregungen und Hilfe, alle!

Verwandte Probleme