Как определить причину прерывания e2fsck

После недавнего сбоя системы несколько моих файловых систем вышли из строя . И даже e2fsck не может их починить.

Удивительно, но в e2fsck отсутствует так называемый режим debugили verboseрежим, и он просто пишет e2fsck: abortedпрактически сразу после запуска Pass 1: Checking inodes, blocks, and sizes. Переходя -C -к fsckпоказам, он прерывается примерно на 0,6%.

Точный вывод e2fsck:

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 выход:

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  

Последние строки вывода строк:

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 +++  

На данный момент я полностью потерян, как это интерпретировать. Единственное очевидное - это то, что все pread64последовательные байты получают доступ, но последний начинается немного назад и вместо 32768 читает 4096. После чего e2fsck прерывается без какого-либо указания. Однако я понятия не имею, если это важно. Я попытался обнулить подозрительные иноды примерно на 0,6% этого объема, но это ничего не изменило.

Я также видел этот вопрос, и это ответ . Это связано с моим вопросом, но ни тот же вопрос, ни ситуация не являются одинаковыми. Напротив, моя проверка всегда прерывается в одно и то же время без какого-либо прогресса, независимо от того, сколько нужно выполнить.

В любом случае, мне интересно, есть ли какой-нибудь способ определить причину прерывания e2fsck, учитывая отсутствие у него опций отладки / подробностей? Причина заключается в том, что я обнаружил неисправный inode или блок или что-то еще, что я мог бы попытаться исправить вручную (например, обнуление), чтобы позволить e2fsck продолжить и в конечном итоге исправить файловую систему.