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.
Tags fsck filesystems ext