SD flash reliability

Hi there. I got a question about the Flash SD card tha tthe Raspberry Pi boots from. With linux writing regularly to log files etc, or reflashing the system, how prone is the SD card to the flash starting to wear out and become less fast?

How long would it work or how often can you reflash it without normal use before it breaks and needs to be replaced ?

Well as an indicator I have a Kingston 4Gb card in my internet facing webserver which is capturing images off a wireless webcam and writing them onto the SD card and then using ImagicMagick to timestamp a second copy for display
This writes two 20kb to 40Kb files EVERY five seconds and has been running for 43 days and 15 hours - so that's one and a half million writes into the root filesystem without issue...

[texy]

Reading/Writing to the SD card is not a problem. Continually plugging the card in and out however is. Since my first Pi delivery - May or June, I,ve broken 4 SD cards now. First they crack, then bits fall off, and eventually the Pi doesn't reconise that it's pluged in. Not the Pi's fault, more my heavy handedness

Texy

the answer to that is to use microSD cards in an adaptor in the SD card slot - don't 'think' this presents any issues with the Pi itself

I struggled to find an answer to this when I wrote a programme that wrote to the card every few seconds, but then found out how to write to the ram !

http://www.maclife.com/article/howtos/a ... e_worth_it

This article says 100,000 but then there is wear leveliing on top of that ?

I found another artucle that tested a flash stick that failed after 90million writes but still could be read.

Gordon77

What about putting just teh bootloader and /boot partition on the flash and have the root filesystem on an external hard disk, would that be possible ?

[texy]

the answer to that is to use microSD cards in an adaptor in the SD card slot - don't 'think' this presents any issues with the Pi itself

I do now have a couple of 4gig micro's with adapters, but in the early days the micro's were not recommended, although that may of been the faster variety.
Texy

I struggled to find an answer to this when I wrote a programme that wrote to the card every few seconds, but then found out how to write to the ram !

http://www.maclife.com/article/howtos/a ... e_worth_it

This article says 100,000 but then there is wear leveliing on top of that ?

I found another artucle that tested a flash stick that failed after 90million writes but still could be read.

Gordon77

well 100k rewrites on todays sd cards is just untrue.. Newer cards are rated from 1k up to about 5k at most, becouse flash gemetry is getting smaller and smaller.You can get more p/e out of them, but that all depends on luck. (most of them dont just die when they hit their rated p/e)

But this is nothing to worry about. Any decent brand name sd card should have somekind of wearlevelling, so it should wear out evenly. Also unless you write to your card like crazy, wearout of card is the last thing to worry about. Even if it does happen, data will still be there, so it can always be cloned to a new card..

I struggled to find an answer to this when I wrote a programme that wrote to the card every few seconds, but then found out how to write to the ram !

http://www.maclife.com/article/howtos/a ... e_worth_it

This article says 100,000 but then there is wear leveliing on top of that ?

I found another artucle that tested a flash stick that failed after 90million writes but still could be read.

Gordon77

well 100k rewrites on todays sd cards is just untrue.. Newer cards are rated from 1k up to about 5k at most, becouse flash gemetry is getting smaller and smaller.You can get more p/e out of them, but that all depends on luck. (most of them dont just die when they hit their rated p/e)

But this is nothing to worry about. Any decent brand name sd card should have somekind of wearlevelling, so it should wear out evenly. Also unless you write to your card like crazy, wearout of card is the last thing to worry about. Even if it does happen, data will still be there, so it can always be cloned to a new card..

So how on my 4Gb card, am I still running with 1,5 million writes? and these are overwriting the same pair of files over and over again...

EDIT - I just checked the script, its actually over 2.2 million writes as there's a 'wget', a 'convert' and then a 'cp' every 5 seconds for the last 43 days

I'm running an e-mail server on the Pi, with 30 e-mail domains, webmail, pop3/imap/smtp, ad well as Pancake + PHP for the web server (I have php doing a lot of file WRITES too, not just reads).

I too was worried about the SD card wearing out, so I moved the operating system onto SSD just to be a bit safer. Runs way faster too


LICK FOR HIGH RES


LICK FOR HIGH RES!

If you're worried, move your operating system onto USB HDD, then you'll be set

http://tafb.yi.org:8000/

-Jamie M.

So how on my 4Gb card, am I still running with 1,5 million writes? and these are overwriting the same pair of files over and over again...

EDIT - I just checked the script, its actually over 2.2 million writes as there's a 'wget', a 'convert' and then a 'cp' every 5 seconds for the last 43 days

You are writing the same pair of files over and over again but you are not writing them to the same physical location on the card. Wear leveling is saving your card.

It seems that SD cards have dynamic wear leveling that writes evenly to the free segments on the card. No invidual segment is written over and over again if there are other free segments.

I too was worried about the SD card wearing out, so I moved the operating system onto SSD just to be a bit safer. Runs way faster too
.

I was wondering about what is the fastest media storage for the RPi is it:

1) SD Card
2) SSD connected via USB
3) USB flash drive
4) Mechanical hard drive connected via USB

I have seen your posts on the SSD and I may give that a try but is the bottlenect the USB interface of the SSD/ hard drive? If it is the latter then does it matter if you are using a SSD or traditional mechanical hard drive?

I was wondering about what is the fastest media storage for the RPi is it:

The order from slowest to fastest would be:

1) SD Card
2) USB flash drive (a good one, i.e. http://www.chaintech.com.tw/a511_newsre ... p?serno=72 )
3) Mechanical hard drive connected via USB (all of them preform about the same)
4) SSD connected via USB (even the cheapest crappiest SSD smokes all the rest).

Obviously the USB interface to the SSD is not ideal, you're getting 30mb/sec write speeds instead of the 500mb/sec it's capable of

Any usb mechanical hard drive will give you great performance on the Pi

-Jamie M.

Why would the SSD be faster than the mechanical hard drive - I guess this implies that random writes to a mechanical hard drive are lower than 30 MB/s, correct? So the bottleneck is the random write (or read) speed of the hard drive and not the USB 2.0 port?

Why would the SSD be faster than the mechanical hard drive - I guess this implies that random writes to a mechanical hard drive are lower than 30 MB/s, correct? So the bottleneck is the random write (or read) speed of the hard drive and not the USB 2.0 port?

It all depends on what you're using it for. Sequential read and write speeds will be almost identical between SSD and physical hard discs on usb 2.0. The big difference comes in small block (4k) random read and write times. The mechanical hard drive just can't keep up with SSD.

If you're using your pi as a server (web, email, whatever) then 4k random performance is important. If you're using it to stream 1080p videos, it's not

-Jamie M.

I would assume (though not tested), that any failure to verify a write places the block in a bad block list, and the SD shrinks in size as bad blocks accumulate. Further processing by adapting the file system could use all the unfailed bits in any bad block, by block triplet majority reads.

It is also important to know the state a bit fails in. Tis could be used to utilize blocks which have minor failures, up to 3 bit loss per failed bit if bits always fail in one bit state i.e. 1.

Failure mainly occurs due to over current in the bit cell charging. Modern SD uses a current regulation charge, as opposed to a fixed voltage inrush current (fail).

Would it be possible to use block compression to extend SD lifespan? Probably. Is it done now? Probably not.

So how on my 4Gb card, am I still running with 1,5 million writes? and these are overwriting the same pair of files over and over again...

EDIT - I just checked the script, its actually over 2.2 million writes as there's a 'wget', a 'convert' and then a 'cp' every 5 seconds for the last 43 days

You are writing the same pair of files over and over again but you are not writing them to the same physical location on the card. Wear leveling is saving your card.

It seems that SD cards have dynamic wear leveling that writes evenly to the free segments on the card. No invidual segment is written over and over again if there are other free segments.

Yeah, you dont actually overwrite your whole card 2m times, as it would surly die (unless you have a really really good card with SLC flash)..

I realize this is a fairly old thread, but this topic is of interest to me, as I'm setting up a couple of Pi's to collect weather data and serve it to the web. One of them got really slow due to poor SD card performance. I replaced the older class 4 card with a new class 10, and now it runs so fast it almost flies.

Given "wear leveling", it occurs to me that one should use a larger card than needed - wouldn't this have a significant impact (reduction) on the wear? My little servers had 4 GB cards and were running at better than 50% free space, but 16 GB Class 10 cards are so cheap now that's what I got. It seems to me that this gives the wear leveling algorithm 4 times the space to use before it has to rewrite any given block, which should be big improvement in reliability, no?

William