linux-ext4 - [Bug 114821] Frequent and recurring ext4 "bad header invalid magic" errors on a healthy drive

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

Message-ID: <bug-114821-13602-JRhgln1z84@https.bugzilla.kernel.org/>
Date:	Sun, 20 Mar 2016 20:50:12 +0000
From:	bugzilla-daemon@...zilla.kernel.org
To:	linux-ext4@...r.kernel.org
Subject: [Bug 114821] Frequent and recurring ext4 "bad header invalid magic"
 errors on a healthy drive

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

--- Comment #8 from Lukas <dse.ssd@...il.com> ---
The command

$ debugfs -c -R 'stat <1523>' /dev/sdb1

produces the following output:

Inode: 1523   Type: regular    Mode:  0644   Flags: 0x80000
Generation: 0    Version: 0x00000000
User:  1001   Group:   100   Size: 0
File ACL: 0    Directory ACL: 0
Links: 1   Blockcount: 0
Fragment:  Address: 0    Number: 0    Size: 0
ctime: 0x56b66f93 -- Sat Feb  6 17:11:31 2016
atime: 0x56b66f93 -- Sat Feb  6 17:11:31 2016
mtime: 0x4e4d75ac -- Thu Aug 18 16:27:24 2011
Size of extra inode fields: 0
EXTENTS:
(END)

Executing 'stat <1523>' command does not cause a head load cycle.

As I understand, there are no blocks assigned to the inode. The file is an
empty text file, so maybe it makes sense? I've created a new empty text file
and it also has no blocks assigned to its inode, but it can be read and stat'ed
with no problems.

I've checked a few of the other inode numbers that appear in dmesg less
frequently and - all of them point to empty text files! I would guess the
reason why inode #1523 appears so often in the logs is because the file is in
the root directory and gets listed each time the root is traversed.

So, is it possible that something went wrong with just the zero-length files
while I was copying my data to it? I did use ext2fsd on Windows 8.1 to copy
some of the files... I just tested it again, and I can copy zero-length files
to the drive using Windows and read them when mounted on linux with no
problems.

And since the zero-length files have no useful information (other than their
file names, which I can still read) and have no blocks assigned to them can I
now just remove them using debugfs?

-- 
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