Como identifico a causa da anulação do e2fsck?

Question

Após uma falha recente do sistema vários dos meus sistemas de arquivos são quebrado . E mesmo o e2fsck falha em repará-los.

Surpreendentemente, o e2fsck não possui o chamado modo debug ou verbose e apenas grava e2fsck: aborted quase instantaneamente depois de iniciar Pass 1: Checking inodes, blocks, and sizes . A passagem de -C - para fsck mostra que é anulado em aproximadamente 0,6%.

Saída exata do 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 output:

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 

As últimas linhas de saída strace são:

pread64(4, "%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%"..., 32768, 8623456256) = 32768
pread64(4, "%pre%%pre%E%pre%\v7%pre%Z%pre%g%pre%0%pre%%pre%E%pre%\v%pre%j%pre%%pre%%pre%%pre%%pre%%pre%x2"..., 32768, 8623489024) = 32768
pread64(4, "%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%"..., 32768, 8623521792) = 32768
pread64(4, "%pre%%pre%<%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%E@ %pre%<%pre%%pre%%pre%%pre%%pre%Z\v%pre%^%pre%0"..., 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 +++ 

Neste ponto, estou completamente perdido em como interpretar isso. A única coisa aparente é que todos os pread64 acessam bytes consecutivos, mas o último começa um pouco de volta e, em vez de 32768, lê 4096. Depois disso, o e2fsck aborta sem qualquer indicação. No entanto, não tenho ideia se isso é significativo. Eu tentei anular inodes suspeitos em aproximadamente 0,6% deste volume, mas isso não mudou nada.

Eu também vi esta pergunta e sua resposta . Está relacionado com a minha pergunta, mas não faz a mesma pergunta, nem a situação é a mesma. Em contraste, a minha verificação sempre aborta ao mesmo tempo sem progresso, não importa quantas execuções sejam executadas.

De qualquer forma, gostaria de saber se existe alguma maneira de identificar a causa do aborto do e2fsck, já que a falta de opções de depuração / verbose Raciocinar é que encontrar inode ou bloco com defeito ou qualquer coisa que eu possa tentar consertar manualmente (por exemplo, zerar) para permitir que o e2fsck continue e conserte o sistema de arquivos.