之后最近的系统故障我的几个文件系统是破碎的. 甚至 e2fsck 也无法修复它们。
令人惊讶的是，e2fsck 缺少所谓的debug或模式，并且在启动后几乎立即verbose写入。传递到显示它在大约 0.6% 时中止。e2fsck: abortedPass 1: Checking inodes, blocks, and sizes-C -fsck
确切的 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
strace 输出的最后几行是：
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% 的可疑 inode 无效化，但什么也没改变。
我也见过这个问题和它的答案。这与我的问题有关，但两者问的问题不同，情况也不相同。相比之下，我的检查总是同时中止，无论运行多少次都没有进展。
无论如何，我想知道是否有任何方法可以确定 e2fsck 中止的原因，因为它缺少调试/详细选项？理由是找到错误的 inode 或块或我可以尝试手动修复它（例如归零）以允许 e2fsck 继续并最终修复文件系统。