linux-ext4 - [Bug 219300] ext4 corrupts data on a specific pendrive

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]

Message-ID: <bug-219300-13602-Js98UzFiYD@https.bugzilla.kernel.org/>
Date: Mon, 23 Sep 2024 16:24:59 +0000
From: bugzilla-daemon@...nel.org
To: linux-ext4@...r.kernel.org
Subject: [Bug 219300] ext4 corrupts data on a specific pendrive

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

--- Comment #7 from nxe9 (linuxnormaluser@...ton.me) ---
Thank you for your entries. My pendrive is not a Chinese fake and I think size
is not correct. At least that's what I think. Intenso is a German company,
although the chips are probably imported from the Far East.

Back to the topic...

I don't know much about file systems, so I'm relying on you. Is it likely that
the file systems are so different that a hardware bug is visible regularly on
one file system but is impossible to reproduce on the other? Besides, the fact
is that two pendrives of the same model have the problem, and other models,
even from the same manufacturer, do not. If I could see the error on ntfs just
once, I wouldn't have a problem, but so far I haven't been able to reproduce
the error on ntfs even once. Today I tested ntfs again with f3 and as usual no
error. Apart from that I generated test data and filled the disk completely. As
usual, all fully consistent on ntfs.

Freespace on ext4 according to f3write: Free space: 28.67 GB
Freespace on ntfs according to f3write: Free space: 29.23 GB

As you can see, I can write even more data to ntfs and it will not generate
errors.

I will summarize some points:
- i/o errors in dmesg appear very rarely. During data corruption this error
usually does not appear.
- f3 tests on ext4 are negative only sometimes.
- when copying my own files to ext4 I can generate data inconsistency very
quickly.
- badblocks doesn't show me any errors.
- ntfs always works great

Therefore, I am still interested in whether one file system can actually hide
hardware defects (or is implemented in such a way that it is very difficult to
reproduce) or maybe the other file system has some rare bug that will only
become visible in the case of this hardware. For me it's not settled.

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

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