linux-ext4 - [Bug 187051] New: "orphan list check failed" error in ext4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <bug-187051-13602@https.bugzilla.kernel.org/>
Date:   Sat, 05 Nov 2016 20:27:15 +0000
From:   bugzilla-daemon@...zilla.kernel.org
To:     linux-ext4@...r.kernel.org
Subject: [Bug 187051] New: "orphan list check failed" error in ext4

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@...nel-bugs.osdl.org
          Reporter: me@...sam.eu.org
        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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html