Raspberry Pi and Micro SD cards

[Mike W]

I have had my B2 for 4 years now and other than the usual issues that most people have, this time has been trouble free. I have however seen many conversations where either the initial problem is a corrupt micro sd card or after trying many different steps the resolution has been to either re-flash or buy a new card.

Is this unique to Brennan or a much more widely spread problem?

Just a few searches unearths many forums where the Raspberry Pi community have been having problems with loss of both boot capability or data as a result of corrupted micro sd cards, so this issue is not unique to Brennan.

Did a bit more searching and reading up on micro sd cards, I didn't realise that the problems with "consumer" type cards was so well known, with the underlying technical reasons clearly explained.

For those who wish to do a bit of reading, head to:

https://manual.raspberryshake.org/burnSD.html

This is a product for earthquake monitoring using a R pi based system. There is a clear explanation as to each type of card and what is recommended. At the bottom of the page are 3 links to additional information which further explain the issue.

In summary the advise is against using the TLC variant which they class as "consumer" other than for products such as cameras and mobile phones where the loss of a pixel in a photo is unlikely to cause significant concern. The frequent failure of this type of card is well known.

For systems where the card will hold an operating environment or requires significantly high read/write cycles, then commercial MLC or industrial SLC cards should be used. The costs of SLC are very high so the MLC is recommended on a cost/benefit basis.

I, along with others, am quite happy to create a new card should mine fail, but others who wish to have a bit more insurance against micro sd card failure should do their own bit of research and decide either to take the risk of continuing to use consumer grade cards or upgrade to MLC or SLC architecture which should prove to be more reliable.

A comparison of capacity/type/costs can be found at:

https://www.mouser.co.uk/Embedded-Solutions/Memory-Data-Storage/Memory-Modules-Memory-Cards/Memory-Cards/_/N-9pk9f?P=1yy7k55Z1yxxwsy

I do not have a deep technical knowledge on the subject, all of the above is from using spare time in lockdown doing a bit of research. Others may be able to add to the conversation.

Mike

[Daniel Taylor]

Mike,

Big thanks for your post.  Great information.  I have saved a copy of the URL for this message for future reference.

[fred.w....@gmail.com]

Hi Mike

Great info - thanks

Fred

[Mike W]

One other bit of information is that the chances of having failures increases with the capacity of the card. There is inbuilt a spare memory pool which is used as the on-card micro-controller detects faulty blocks and replaces them with blocks from the spare pool. This carries on until all of the spares are used up. At this point no further data can be written to the card.

With this in mind it's probably best not to use a card greater than 8gb which should be sufficient for the operating  software for some time.

Mike

[Peter Lowham]

Hi Mike,

Thank you very much for this information; it's very useful.  I have a bee in my bonnet with regard to using cheap micro(SD) cards in the Brennans (and anywhere else in fact) and did post to this forum on the subject about a year ago.  I included a web link to a piece of software that tests your card and gives a 'Pass' or 'Fail' status and it produced some interesting results for a number of people who were posting about 'having problems on my B2'.A quick software test and the response was 'oops the SD card is faulty'.

Regards,

Peter.

[Edwyn Corteen]

For another upvote for this look at Dash Cam user groups, they buy cheap SD cards and wonder why their recordings keep failing! The Good thing about the B2 is the SD card is not repeatedly written to, it is write only during software upgrades and read only the rest of the time.

[hbu...@gmail.com]

That's great Mike, a very useful post. 

[MJB]

Hi Mike

Thanks for that bit of research - Paul forwarded it to me. I knew from my days as a chip designer that flash errors and wear out is a fact of life.

In fact I assume that the controllers in SD cards work with errors continually and use error correction (ECC) to put things right. They can then use bad block mapping to swap in/out redundant or irretrievably bad sections of memory.

ECC is such a powerful technique that in domains like storage and communication the philosophy is that if you are not getting errors you are not pushing the medium hard enough. [And if you are not pushing it hard enough - your competitors will]

Your mobile phone uses ECC (and other measures) to deliver good data amid noise.

I would speculate that the SD manufacturers even target file systems like FAT32 (most cameras) and treat some sectors in the file system as more critical than others - the files themselves. That way an irrecoverable error only affects one file not the entire disk.

The idea that an error would only affect one pixel is a bit simplistic. In fact the disk would refuse to deliver data that it knew to be corrupt so generally the entire file would be unreadable (unless you were using a disk recovery tool). Beyond that most photographs are compressed - jpeg being the most common format. I can't remember all the details of jpeg encoding but you would expect an error to knock out an 8x8 array of pixels - those weird blocks you sometimes see on TV - if not the entire file.

As it happens we are currently looking at this issue from a software perspective - there may be ways to eliminate or at least minimise writes to the SD card.

Martin

[Mike W]

Thanks Martin, I think that anything which will help minimise the possibility of micro sd card failure will be a great step forward.

The SLC technology is too cost prohibitive for something like the Brennan but MLC type cards together with fewer read/write cycles may be a way to improve failure rates.

Is there a possibility to have an alternative boot option such as inserting a usb storage device in the event of an internal sd card failure? Not sure if the R Pi supports this?

Regards

Mike