20
Create image from SSD with I/O errors
(lemmy.world)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 05 Oct 2023
20 points (95.5% liked)
Linux
48186 readers
1371 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
Thanks for the input, guys. I consider my issue resolved.
As for the specific question I head,
ddcan fill with zeroes the blocks that failed to read withconv=noerror,sync. However, this puts the zeroes at the end of the block and not over the exact bit/byte that failed to read, meaning that a read error will invalidate the rest of the block.But the consensus across source I searched seems to be to use
ddrescueinstead ofdd.There is no particular bit or byte that is wrong. The drive is coming from an entire 128K to megabytes-large page that it couldn't make sense of. There was already a lot of error correction code tried, and the overall analog values of the page were re-tried (was this a 14/16th millivolt, or a 15/16th millivolt?). That page couldn't be made sense of, the MLC page overlaid on it couldn't be made sense of, the TLC page overlaid on that couldn't be made sense of, etc. Or things could also be so bad that the FTL doesn't even know which flash cells your data should be found in.
Everything that I understand about flash storage suggests that it can't reasonably do little errors. You could still get small errors from a bit flip in delivery, or more likely flips in your PC's own ram. But the flash itself should either be very right, or very very wrong. Nothing in-between.
Thanks for the explanation. I don't really know how flash storage works. The fundamental idea of the problem I described would still apply, though as long as the input block size for
ddextends to more than one page of the underlying storage.For example, say that exactly three pages fit in a block. If
ddattempts to read pages A, B and C (ABC) and fails to read B, you would want the corresponding part zeroed in the output to preserve the offsets of all the other pages (A0C). But insteadddreads whatever it can for the entire block, then pads the rest of the block size with zeroes, effectively moving C forward (AC0). So essentially you magnify errors.