Wie identifiziere ich die Ursache für den Abbruch von e2fsck?

Nach einem kürzlich aufgetretenen Systemfehler sind einige meiner Dateisysteme beschädigt . Und selbst e2fsck kann sie nicht reparieren.

Überraschenderweise fehlt e2fsck der sogenannte debugor- verboseModus und schreibt e2fsck: abortedfast sofort nach dem Start Pass 1: Checking inodes, blocks, and sizes. Das Weitergeben -C -an fsckzeigt, dass es bei ungefähr 0,6% abbricht.

Exakte e2fsck-Ausgabe:

e2fsck 1.43.4 (31-Jan-2017) /dev/mapper/data-home_copy contains a file system with errors, check forced. Resize inode not valid. Recreate<y>? yes Pass 1: Checking inodes, blocks, and sizes e2fsck: aborted  /dev/mapper/data-home_copy: ***** FILE SYSTEM WAS MODIFIED *****  

dumpe2fs -h Ausgabe:

dumpe2fs 1.43.4 (31-Jan-2017) Filesystem volume name: <none> Last mounted on: /mnt Filesystem UUID: 2af6ad0c-1fb0-415b-9db1-01d044ab6e0c Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: ext_attr resize_inode dir_index filetype extent flex_bg inline_data sparse_super large_file huge_file dir_nlink extra_isize Filesystem flags: signed_directory_hash Default mount options: user_xattr acl Filesystem state: not clean with errors Errors behavior: Continue Filesystem OS type: Linux Inode count: 72089600 Block count: 288358400 Reserved block count: 14416320 Free blocks: 104523485 Free inodes: 69009804 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 955 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8192 Inode blocks per group: 512 RAID stride: 64 RAID stripe width: 384 Flex block group size: 16 Filesystem created: Fri Jun 13 15:37:57 2014 Last mount time: Thu Nov 9 18:05:58 2017 Last write time: Sat Nov 18 00:28:30 2017 Mount count: 14 Maximum mount count: -1 Last checked: Wed Feb 1 15:26:27 2017 Check interval: 0 (<none>) Lifetime writes: 2680 GB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Default directory hash: half_md4 Directory Hash Seed: bf864678-00c0-4675-94fe-00593a3f1eae Journal backup: inode blocks FS Error count: 176200 First error time: Fri Oct 27 00:00:01 2017 First error function: ext4_lookup First error line #: 1611 First error inode #: 13762561 First error block #: 0 Last error time: Fri Nov 10 01:57:02 2017 Last error function: ext4_lookup Last error line #: 1611 Last error inode #: 60818277 Last error block #: 0  

Letzte Zeilen der Strace-Ausgabe sind:

pread64(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32768, 8623456256) = 32768 pread64(4, "\0\0E\0\v\377\7\0Z\3\0g\0\7\300\6\0\35\0E\0\v\0j\0\0\0\0\0\0x\232"..., 32768, 8623489024) = 32768 pread64(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32768, 8623521792) = 32768 pread64(4, "\0\35\0<\0\0\0\0\0\0\0\0\0\0\0E@ \0<\0\0\0\0\0Z\v\0^\0\10\300"..., 4096, 8623525888) = 4096 write(2, "e2fsck: aborted\n", 16e2fsck: aborted ) = 16 fsync(4) = 0 write(1, "\n/dev/mapper/data-home_copy: ***"..., 66 /dev/mapper/data-home_copy: ***** FILE SYSTEM WAS MODIFIED ***** ) = 66 exit_group(9) = ? +++ exited with 9 +++  

An diesem Punkt bin ich völlig vergessen, wie ich das interpretieren soll. Das einzige, was offensichtlich ist, ist, dass alle pread64auf aufeinanderfolgende Bytes zugreifen, aber das letzte beginnt ein wenig zurück und liest statt 32768 4096. Danach bricht e2fsck ohne Angabe ab. Ich habe jedoch keine Ahnung, ob das von Bedeutung ist. Ich habe versucht, verdächtige Inodes für ungefähr 0,6% dieses Volumens zu annullieren, aber es hat sich nichts geändert.

Ich habe auch diese Frage gesehen und sie ist die Antwort . Es bezieht sich auf meine Frage, aber weder die gleiche Frage noch die Situation ist dieselbe. Im Gegensatz dazu bricht mein Check immer zur gleichen Zeit ab, egal wie viele Läufe zu machen sind.

Wie auch immer, ich frage mich, ob es einen Weg gibt, die Ursache für den Abbruch von e2fsck zu identifizieren, da es an Debug- / Verbose-Optionen fehlt. Grund dafür ist, dass ich einen fehlerhaften Inode oder Block gefunden habe oder was auch immer ich versuchen könnte, den Fehler manuell zu beheben (z. B. Nullstellen), damit e2fsck fortfahren und das Dateisystem letztendlich reparieren kann.