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

Date:	Sun, 20 Mar 2016 06:46:35 +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 #6 from Lukas <dse.ssd@...il.com> ---
I agree, the head cycling does seem unlikely to be caused by software. But I'm
confused how can the drive be 'failing' simple reads so often and yet pass
every fitness, including a vendor diagnostic test of every sector...

I cannot create a drive image... It is 4TB in size and I don't have that much
contiguous free storage at my disposal. What I could do is wipe the drive and
re-create the ext4 partition. I have most of the contents backed up. It sounds
like a radical way of testing, but let me know if that's my only option.

In the mean time I've done some more testing. Maybe it will prove useful.

Firstly, I've reproduced the error on Raspbian 8 with 4.1.18-v7+ kernel running
on a different Raspberry Pi device. (Sorry, the kernel is again non-vanilla).
Upon accessing a particular file on the drive, I can hear the head load cycle
and a dmesg ext4 error is logged.

Secondly, I've noticed that most of the ext4 errors are due to smbd and for the
same inode #1523. That inode seems to be accessed quite often whenever I do
anything with the drive.

I ran

$ debugfs -R "ncheck 1523" /dev/sdb1

and determined that the inode holds a single text file in the root directory of
the drive - 'file.txt'. I cannot list or delete this file:

% ls -li

ls: cannot access file.txt: Input/output error
? -?????????  ? ?     ?               ?            ? file.txt

$ rm file.txt
rm: cannot remove `file.txt': Input/output error

If I execute

$ debugfs -R 'cat <1523>' /dev/sdb1

it returns nothing and I believe the file should be empty. The command takes a
few minutes to execute, which I don't think is normal too.

I know this sounds even more like hardware problems, but, again, there's
nothing in the SMART attributes, self-tests or vendor diagnostic tests to
support that.

Should I attempt to delete this file using debugfs? Or should I re-create the
partition from scratch? Or should I just get another drive, close this 'bug'
and stop troubleshooting?

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