linux-ext4 - [Bug 215879] EXT4-fs error - __ext4_find_entry:1612: inode #2: comm systemd: reading directory lblock 0

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-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 26 May 2022 19:18:29 +0000
From:   bugzilla-daemon@...nel.org
To:     linux-ext4@...r.kernel.org
Subject: [Bug 215879] EXT4-fs error - __ext4_find_entry:1612: inode #2: comm
 systemd: reading directory lblock 0

https://bugzilla.kernel.org/show_bug.cgi?id=215879

Vladimir G. Ivanovic (vladimir@....org) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vladimir@....org

--- Comment #4 from Vladimir G. Ivanovic (vladimir@....org) ---
I am getting the same error as sander44 (the OP) reported except the name of
the program generating the error is different.

EXT4-fs error (device sdb1): __ext4_find_entry:1612: inode #2: comm vorta:
reading directory lblock 0

The behavior of the Samsung 1TB SDXC card is predictable. It works for
minutes/hour, then throws the above error. This particular SD card is used for
borg backup which occur every 15 minutes (and also every 3 hours).

My (temporary) workaround is to unmount the SD card, run e2fsck, then re-mount
the card.

I'm suspicious of this being exclusively a hardware error because it is always
the same error at the same spot. Might it be an unexpected call or unexpected
function arguments? (I have no knowledge of ext4 internals, so it's likely I'm
talking nonsense.)

I'm happy to provide more detail or even roll my own kernel to provide
debugging symbols. (I'm using Arch 5.15.43-1-lts, but the error is independent
of what kernel I'm using.)

— Vladimir

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.