3
\$\begingroup\$

I have been happily backing up and copying SD (including microSD and SDHC) cards from a Linux PC using the following commands:

dd if=/dev/sdb of=sd.img bs=4096 conv=notrunc,noerror
dd if=sd.img of=/dev/sdc bs=4096 conv=notrunc,noerror

However, I know that there is the possibility for blocks to go bad on the SD card. I assume that this failure can occur on read or on write.

My question is, what happens on a read error? Do the errored bytes get set to 0x00 in the image file? Do they get set to 0xFF? Or do they disappear (changing the file size)?

Likewise, on write, what happens when there is an error? Will the SD card automatically write the data to another block? Or will something else happen?

\$\endgroup\$
  • 1
    \$\begingroup\$ This is a high level system question, not about the electronics of flash memory. \$\endgroup\$ – Olin Lathrop Apr 11 '13 at 12:12
  • \$\begingroup\$ You might want to try Super User instead. \$\endgroup\$ – user17592 Apr 11 '13 at 13:09
  • 2
    \$\begingroup\$ There are two inherent questions here, which should perhaps be asked on different forums: (1) what does an SD card do if it is unable to satisfy a read or write request, and (2) what does Linux do if that happens. I'd be interested in an answer to the first question (if anyone knows), and that question would be topical here. \$\endgroup\$ – supercat Apr 11 '13 at 16:36
1
\$\begingroup\$

While how Linux or another OS handles bad blocks varies both OS, drive type, and file system type, as well as application used (in your case, DD) you would have better luck trying to ask that on Superuser.stackexchange.com

But just for completion's sake, DD when ran with the noerror flag, will skip over bad blocks/read errors, instead of stopping. Without the sync flag, it will simply skip those errors, so your output file will be smaller. The sync flag does:

Pad every input block with NULs to ibs-size; when used with block or unblock, pad with spaces rather than NULs So if you use notrunc,noerror,sync, any read errors will be written as \x00 or NUL, and the output will be the same size as the input.

As for how the SD card handles it, SD cards are Nand Flash memory with an embedded controller, which handles wear leveling, bad block management, and mapping the virtual file system to physical locations in the Nand memory. Part of it is that memory sectors have spare blocks, for if a few blocks in a sector die. It tries to write the data to the main block, read back to check if valid, then if not, uses those spares. It then marks the bad block as such. It's unknown if when a spare block section is used up if the entire sector is marked bad or not.

But this is all on the SD's internal controller's side. None of this is ever reported back to the OS. Bad Blocks in the Nand are not managed by the User/Application.

\$\endgroup\$
  • \$\begingroup\$ Thanks for humoring my question and giving a detailed answer! I suppose this question would have been better addressed to a Linux forum, since it seems to be up to dd to decide what to do with the errors. I suppose all that remains relevant to the the hardware domain is how the SD card responds when a read or write operation fails. I gather that an error is generated and passed up to the calling application, in this case dd, to make of it what it will. \$\endgroup\$ – Chris Merck Apr 12 '13 at 12:05
  • 1
    \$\begingroup\$ @ChrisMerck the issue is that there is multiple types of read errors, when it comes to SD cards. The first is SD controller to Nand read error. It's hidden away from the os. Then there is the sd reader to the sd controller. And then there is the computer to the sd reader. With luck, the second passes the error to the computer, as does the third, but the raw nand error isn't communicated up. \$\endgroup\$ – Passerby Apr 12 '13 at 12:12
  • \$\begingroup\$ @ChrisMerck that is to say, any dd read error will be from a failure to communicate with the SD's internal controller, not from a failure to read from the raw nand memory. \$\endgroup\$ – Passerby Apr 12 '13 at 12:13
  • 1
    \$\begingroup\$ @supercat that's the problem, there is none. SD cards do not indicate if there is a problem or not. The user has to interpret that from when it fails. As for read/write failures, the SD spec requires the host computer to assume failure if the card does not respond. As for the specs, the SD association has a simplified specs online, sdcard.org/downloads/pls/simplified_specs/part1_410.pdf is one part. Section 4.6 deals with some error conditions, again, only on the host/controller side, not the nand side. \$\endgroup\$ – Passerby Apr 13 '13 at 4:38
  • 1
    \$\begingroup\$ The URL for spec referenced by @Passerby is now available at sdcard.org/downloads/pls (original is on wayback at web.archive.org/web/20131202232415/https://www.sdcard.org/… ) \$\endgroup\$ – jhfrontz Aug 30 '18 at 19:37
1
\$\begingroup\$

This very much depends on exact behaviour of a lot of parts in the system, but in my experience of bad discs you get something returned from the bad block; the file size will not be shorter. The "bad data" could be 00, FF, or a scrambled version of the real data.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.