After a recent system failure several of my filesystems are broken. And even e2fsck fails to repair them.
Surprisingly e2fsck lacks the so called debug or verbose mode and just writes e2fsck: aborted almost instantly after starting Pass 1: Checking inodes, blocks, and sizes. Passing -C - to fsck shows that it aborts at approximately 0.6%.
Exact e2fsck output:
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
Last lines of strace output are:
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 +++
At this point I'm completely lost on how to interpret this. The only apparent thing is that all pread64 access consecutive bytes, but the last one starts a bit back and instead of 32768 reads 4096. After which e2fsck aborts without any indication. However I have no idea if that is significant. I have tried nullifying suspicious inodes at approximately 0.6% of this volume, but it didn't change a thing.
I also have seen this question and it's answer. It is related to my question, but neither it asks the same question, nor the situation is the same. In contrast mine check always aborts at the same time with no progress no matter how many runs to do.
Anyway I wonder if there is any way to identify the cause of e2fsck abort given it's lack of debug/verbose options? Reasoning is that finding faulty inode or block or whatever I could try to fix it manually (e.g. zeroing) in order to allow e2fsck to continue and ultimately fix the filesystem.
