linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 06:26:35 +0000	[thread overview]
Message-ID: <bug-219300-13602-Tor3Eyz3zS@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-219300-13602@https.bugzilla.kernel.org/>

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

Theodore Tso (tytso@mit.edu) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tytso@mit.edu

--- Comment #5 from Theodore Tso (tytso@mit.edu) ---
Ext4 uses a block allocation algorithm which spreads the blocks used by files
across the entire storage device in order to reduce file fragmentation.   There
are cheap thumb drives that claim to be, say, 16GB, but which only have 8GB of
flash, and they rely on the fact that some Windows file systems (FAT and NTFS)
allocates blocks starting at the low-numbered block numbers, and so if there is
a fake/scammy USB thumb drive (the kind that you buy in the back alley of
Shenzhen, or at a deap discount in the checkout line of Microcenter, or a
really dodgy vendor on Amazon Marketplace at a price which is too good to be
true), it might work on Windows so long as you don't actually try to store that
many files on it.

In any case, the console messages are very clearly I/O errors and the LBA
sector number reported is a high-numbered address: 60278752.    Whether this is
just a failed thumbdrive, or one which is deliberately sold as a fake is
unclear, but I would suggest trying to read and write to all of the sectors of
the disk.   Fundamentally, ext4 assumes that the storage device is valid; and
if it is not valid (e.g., has I/O errors when you try to read or write to
portions of the disk), that's the storage device's problem, not ext4.

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

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

  parent reply	other threads:[~2024-09-23  6:26 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 [this message]
2024-09-23  7:07 ` bugzilla-daemon
2024-09-23 16:24 ` bugzilla-daemon
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-Tor3Eyz3zS@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).