From: bugzilla-daemon@kernel.org
To: linux-ext4@vger.kernel.org
Subject: [Bug 219300] ext4 corrupts data on a specific pendrive
Date: Mon, 23 Sep 2024 16:24:59 +0000 [thread overview]
Message-ID: <bug-219300-13602-Js98UzFiYD@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-219300-13602@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=219300
--- Comment #7 from nxe9 (linuxnormaluser@proton.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.
next prev parent reply other threads:[~2024-09-23 16:24 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-22 15:47 [Bug 219300] New: ext4 corrupts data on a specific pendrive bugzilla-daemon
2024-09-22 18:58 ` [Bug 219300] " bugzilla-daemon
2024-09-22 18:59 ` bugzilla-daemon
2024-09-23 1:35 ` bugzilla-daemon
2024-09-23 1:39 ` bugzilla-daemon
2024-09-23 6:26 ` bugzilla-daemon
2024-09-23 7:07 ` bugzilla-daemon
2024-09-23 16:24 ` bugzilla-daemon [this message]
2024-09-23 16:30 ` bugzilla-daemon
2024-09-23 18:53 ` bugzilla-daemon
2024-09-24 16:15 ` bugzilla-daemon
2024-09-25 16:49 ` bugzilla-daemon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-219300-13602-Js98UzFiYD@https.bugzilla.kernel.org/ \
--to=bugzilla-daemon@kernel.org \
--cc=linux-ext4@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).