После недавнего сбоя системы несколько моих файловых систем вышли из строя. И даже 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 мог продолжить и в конечном итоге исправить файловую систему.