You are not logged in.
Pages: 1
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 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.
I pretended something was wrong and the shop replaced it with the same model.
I restored the backup. 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.
Would you say this is a hardware issue or kernel bug?
I can buy the 2TB model but also the same manufacturer.
Checking the inode that caused the hiccup reveals it points to a folder in /usr 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.
Anyway, thanks in advance for any help or input.
Offline
Kernel bug, otherwise you would be seeing I/O error messages in dmesg mixed with these.
Offline
Ok, thank you very much, mich. I'll go ahead and file a bug in kernel.org bug tracker.
Offline
Pages: 1