https://bugzilla.kernel.org/show_bug.cgi?id=187051 Bug ID: 187051 Summary: "orphan list check failed" error in ext4 Product: File System Version: 2.5 Kernel Version: 4.8.6 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: ext4 Assignee: fs_ext4@xxxxxxxxxxxxxxxxxxxx Reporter: me@xxxxxxxxxxxxx Regression: No I saw a ext4 "orphan list check failed" in my logs. It is happening on a new 1TB hard disk and mostly when idle. I did a smart check and a a fsck check for bad sectors from the arch linux rescue usb. neither saw anything. I formatted the disk again and restored a backup. Then I thought I would just get a replacement instead of wait for this to happen again. Same issue happened 50 minutes ago. "Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum". and formatted under kernel 4.8 with latest e2fsprogs. Checking the inode that caused the hiccup reveals it points to a folder in /usr/share/ that was not touched since the 25th of last month and I have fscked and rebooted plenty of times since then. I fsck on each reboot anyway. I did a fsck -D -fv /dev/mapper/root from rescue usb after last reboot too. Could the metadata_csum option be causing this? the kernel.org ext4 wiki suggested it is a integrity measure. My backups don't include system journals to save space on backup media so I don't have the full kernel crash log. I am sure there was no I/O error message in the crash log when I typed dmesg and I was told on arch linux logs that this rules out any hardware errors. I believe this is the second time this has happened. -- You are receiving this mail because: You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
