1

I've done a bit of research and I've heard of the SD card end-of-life behavior (not really sure what else to call it) where SD cards and microSD cards make themselves read-only to avoid data loss. When I first heard of it, I thought it was terribly clever. Now I'm not so sure.

Some background: I had a microSD which lasted 2 years of heavy raspberry pi use before putting itself in write-protect mode. I used dd to move the whole os and filesystem onto my replacement card. Within a few days of usage, I realized that this card had write-protected itself too. I thought I had terrible luck, until my second backup card did the same almost immediately.

This troubled me, so I've since let my raspberry sit off. But I've begun to wonder how the SD card knows to write-protect itself. If it keeps a count of the write-cycles, and I used dd to make an image of the whole disk, then I may have crippled my SD cards by tricking them into thinking they were old. But I can't find the implementation of the end-of-life behavior anywhere. Does anyone know how it works? I'd like to try to undo it but the write-protection seems to be implemented on a very low level. I can't even access the /dev/sdX using sudo.

If I'm right and it keeps some kind of write-cycle tally, this is more than a little frustrating. It means that the SD card hasn't actually died – it's just a precautionary measure. While this is nice, I'd like to use it all the way to actual death, as I'm making regular backups.

With that as my long-winded background, does anyone know how the end-of-life behavior is implemented, and is there any way I can undo an accidental triggering of the behavior?

Improve this question
3
  • I believe that it is detection of an internal error that prompts reversion to read only mode. These devices were made to be cheap, not reliable. Typically this is non reversible, at least without undocumented drive specific information.
    – LMiller7
    Commented Mar 6, 2018 at 5:39
  • 1
    @fixer1234, umm.. no. That kind of information is internal to the drive and not visible to dd.
    – psusi
    Commented Mar 6, 2018 at 17:13
  • @LMiller7 do the devices check for internal errors each time? The cards themselves are 1 write-cycle from brand new and shouldn't have any error except in the data I wrote to them, which might be data corruption but not internal errors, right?
    – Sllew
    Commented Mar 7, 2018 at 17:13

2 Answers 2

Reset to default
2

Most manufacturers do not publish their wear leveling mechanism which makes it impossible to determine the best and worst life expectancy scenarios (probably that is the reason because with that knowledge one could destroy such a card within no time).

SanDisk did provide some insight though quite a while ago (https://web.archive.org/web/20150326122100/http://ugweb.cs.ualberta.ca/~c274/resources/hardware/SDcards/WPaperWearLevelv1.0.pdf). While this probably has changed or been refined, the basics should still apply:

Each memory chip is divided into blocks. A block is an array of memory cells organized as sectors. (...) The minimum unit for a write or read operation is a page (or sector). The minimum unit for an erase operation is a block. Physical blocks are logically grouped into zones. (...) Wear leveling is done within a zone. The current firmware does not spread the wear across the capacity of the card. Each zone has about 3% additional “spare blocks” beyond what is assigned to meet the logical capacity of the flash card. This group of blocks is commonly referred to as the “Erase Pool”.

Even if the wear is spread over the card, the principle remains the same.

When a card detects that a block has reached the end of its useful life, it removes that block from the blocks that are available for write operations. The result is a reduction of the size of the erase pool. This does not affect the capacity of the card as seen by the host. When the pool of blocks available for write operations has been exhausted due to wear, the card will reach the end of its useful life for write operations.

Because the capacity of the card is not reduced and wear leveling on consumer card do not rewrite stored data (as in SSDs), some type of writes may quickly wear a card. One type is writing only to a sector which requires the whole block to be written. Depending on your operating system, dd may use a default blocksize of 512 which may be much lower that the blocksize of the card and therefore result in huge write amplification. An example: when the block size of the SD cards is 16kB and one sector is 512 Byte, the amount of wear can be increased in this case up to the factor of 31! This could be the reason why your second card failed early.

The wear information is not copied because it is part of the sdcard hardware and therefore this information cannot be read/restored by normal means. The same applies to the write protection, as the SD cards controller itself prevents this. So, no, if we are not talking about hardware (mechanical switch in SD cards) or software (mounting read-only) write protection, this process is not reversible.

Improve this answer
1

The cards are supposed to have some extra space in them to use for wear leveling, but it sounds like maybe the ones you have are dumb and don't have any spare blocks and are going read-only because you have written to every block on the drive. Copying the files instead of using dd, or using e2image -ar to copy an ext[234] filesystem will avoid needlessly writing to every unused block on the disk, which may help.

Improve this answer
2
  • Thanks for the recommendation, but I figured this all out the hard way. My question was whether there's anything that can be done about the cards that are needlessly read-only.
    – Sllew
    Commented Mar 7, 2018 at 17:16
  • @Sllew, I'm not sure if sdcards support fstrim, but that might help.
    – psusi
    Commented Mar 7, 2018 at 17:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .