5

I've seen several posts about SD card lifespan, however I'm still a bit confused about it.

In my case, I have Raspberry Pi B+ running slideshow from image and HD video (~40MB) in OpenELEC/Kodi, all day long, reading from the SD card. The SD card is SanDisk 8GB class 10.

It is located on a shopping, so if it gets down I'm somewhat fired.

I have another RasPi for backup, and another SD image prepared for the worst.

Am I doing right?

whitenoisedb
  • 367
  • 1
  • 5
  • 13
  • Do you have pictures on hdd or on sd? – KernelPanic Mar 20 '15 at 05:14
  • pictures and videos on SD card. I tranfer them into it using Samba – whitenoisedb Mar 20 '15 at 05:33
  • 2
    Well, why don't you move media contets to show to some more "risk-free" media, like, USB HDD that can be plugged into rPi B+? – KernelPanic Mar 20 '15 at 06:08
  • I'm not sure about mounting the USB HDD, or if it will be automounted after reboot. Also I should have to configure my samba media folder I guess. – whitenoisedb Mar 20 '15 at 06:56
  • Is it really risky using the SD card, or you say that just in case? – whitenoisedb Mar 20 '15 at 06:56
  • I'm not an expert, but won't the media get cached since it is only 40MB? – user236012 Mar 20 '15 at 07:43
  • As long as it isn't defective, that card will last you for years. Don't worry. But maintaining a (as in one) backup is essential regardless. – goldilocks Mar 20 '15 at 10:34
  • I use Samsung EVO 32 and 64GB cards in my Pi 2's and 4K random read and write speeds are good. Also used them with cheap power supplies so the Pi was constantly underpowered and had no corruption of any kind. They will probably die long after I am. – unom Mar 20 '15 at 16:17

1 Answers1

10

I've seen several posts about SD card lifespan

Then please be sure to read mine, which is the other side of the coin from all the "OMG! Your SD card is in danger! You need to protect it now by reading my blog!" stuff:

https://unix.stackexchange.com/questions/84902/pimp-rsyslogd-to-have-less-i-o-cron-pam-and-less-logging

And a sort of tangent to that which gets into methodology for stress testing SD cards to see just how long they will last:

https://unix.stackexchange.com/questions/96774/stress-testing-sd-cards-using-linux

I'll quote the first one:

If your system writes a MB of logs a day [...] and you have a 4 GB card, it will take 4000 days before such a cycle has written to the entire card just once. The actual lifespan of an SD card might be as much as 100,000 write cycles. So all that logging will wear the card out in 4000 * 100000 / 365 =

~ 1 million years

Note that unless your system is very busy, it won't be logging nearly that much anyway. Since pi oriented distros such as raspbian use tmpfs (i.e., RAM) for /tmp and /run, that pretty much covers what the system will do as a matter of course. Your own actual activity will be much more significant -- if you were actually averaging 100 MB of writes per day, this would be reduced to 10 000 years.

Of course, that's a bit of an exaggeration as it is based on the idealized lifetime of 100 000 write cycles for the card. That probably only applies to very high end cards. Let's assume a very low end of only 1000 write cycles -- now we are down to just 10 years at 100 MB a day for a cheap 4 GB SD card.1

Note this is about writes and not reads, which are much less expensive wear wise. What wears the card out is erasing (which it must always do before writing, a characteristic of some solid state storage is that all bits are set one way before data is written).

I have Raspberry Pi B+ running slideshow from image and HD video (~40MB) in OpenELEC/Kodi, all day long, reading from the SD card.

Here's a great feature of modern operating systems including linux: file caching. If you have 512 MB of RAM but only use 350 MB of it, the OS has 150 MB left over to use as a cache (you can see this with tools like free or top which may include that in their total, making it seem as if you are using all of it -- pay attention to the "buffers/cache" figure). It will use that to store frequently read data so it doesn't have to read from disk all the time. If you are constantly reading a 40 MB film over and over, there's a very good chance that all or most of that will be cached in RAM, i.e. most of the time it won't really be reading from the SD card.

In your case, you might want to guarantee this for yourself by mounting a small tmpfs partition at boot and copying your movie, etc. into there. Tmpfs is in RAM, so that means you are guaranteed no SD card reads, hooray.

This may all seem to go against the hundreds of people who have reported various places online (including here) that their brand new SD card keeps getting corrupted in the pi. I am not calling these people liars, but it is worth considering a few things.

  • There are millions of raspberry pis in the world.
  • There are tens or hundreds of millions of SD cards in use everyday, in phones, cameras, etc.

No one goes on line to announce, "Hey, guess what? My pi's been on for two years with the same SD card -- no problems so far!". It's true for me, and true for a lot of other people as well I am sure.

It seems to me looking around that complaints about SD card corruption are reported disproportionately by pi users (but this could also have to do with my search profile). It could well be that there are some pis out there that have some defect that is causing this problem, or because of the nature of the power system under certain circumstances.

But there's no point worrying about that until it happens, because it probably won't, and if it does, there's not much you can do about bad hardware except replace it.

A tip about filesystems in general that probably applies even more so to ones on SD cards because of the mechanism described below: Don't fill them to capacity. Stay below 75-80% and ideally, closer to 50%. So if you have an 8GB card, think about it as a 6GB card and don't fill it beyond that. If you know you need 8GB, buy a 16 GB card. This logic doesn't apply to things like cameras, BTW, just root filesystems for devices like the pi.

1. A somewhat tech savvy person might object that this is still very idealized since some physical blocks are prone to get used much more than others. That person is unaware of wear levelling <- read this to be even more tech savvy ;) SD cards have a logic chip in them and use virtual addressing to spread wear evenly, maximizing their lifespan.

Community
  • 1
goldilocks
  • 56,430
  • 17
  • 109
  • 217
  • What about if the logic chip managing the wear levelling is the bottleneck concerning lifespan? Edit: Otherwise fully d'accord with @goldilocks. – user236012 Mar 20 '15 at 10:39
  • @user236012 You mean that logic chip may wear out? Probably -- I don't really believe they're going to last a million or even a hundred years. Stuff inevitably breaks, which is why it is always important to maintain a backup. They are so cheap anyway, even if it only lasts a year or two and you have that backup, when it finally fritzes out you can just replace it. – goldilocks Mar 20 '15 at 10:51
  • Really thanks for your answer. You've replied all new questions that emerged to me while I was reading it. Also, interesting links to check. Just one thing about cache I'm not sure about. Kodi has an [advancedsettings.xml](http://kodi.wiki/view/HOW-TO:Modify_the_cache#Cache_settings) file in which you can set buffermode to 1. That means "Buffer all local and internet files". Default is 0 (only internet files), would it be still caching my playing media files stored in sdcard? It should be caching somewhere... – whitenoisedb Mar 20 '15 at 17:59
  • I've read your post several times. I was really concerned about SD card risks. – whitenoisedb Mar 20 '15 at 18:01
  • Looks to me that if you want Kodi to buffer local files you'd need to set buffermode to 1. However, I'm not too sure that means it is going to keep it cached unless it has a loop setting to play over and over and/or is smart enough. You might be able to tell by watching what happens with your free mem. But the surest bet IMO is still to use tmpfs -- although that's beyond the scope of this question, it is pretty simple: http://www.thegeekstuff.com/2008/11/overview-of-ramfs-and-tmpfs-on-linux/ You can set that up and copy stuff into it at boot via `/etc/rc.local`. – goldilocks Mar 20 '15 at 18:10
  • Thanks. I think OpenELEC is slightly different on directories, I mean, I guess I can't write into `/etc`, everything is read-only or it is loaded (mounted maybe?) on every boot. I can only tweak files inside `/storage/.config`, `/storage/.cache`, where `/storage` is the sdcard directory. I know that if I was in Raspbian I could do what you're explaining me. – whitenoisedb Mar 20 '15 at 21:47
  • By the way, if I see bytes inside the Buffers or Cache column when doing `free` it means cache is allocated (probably because of my looped playlist media files)? – whitenoisedb Mar 20 '15 at 21:51
  • Yeah. If the system is being used, it will over time absorb most or all of the free ram as cache, because it might as well: this doesn't restrict the amount actually available -- if a process suddenly needs more, the cache is cleared out to provide it. So with `free`, the real amount of available ram is on the second line (`+/- buffers/cache`) in the `free` column. This is why it can get a little confusing WRT how much memory is committed. – goldilocks Mar 20 '15 at 22:10
  • I'll have to read about how openelec works, but I remembered there was a file called `/storage/.config/autorun.sh` where I can include some bash lines at boot. – whitenoisedb Mar 20 '15 at 23:46
  • Whoops -- I missed your comment about the peculiarities of openELEC. I haven't used it but I think you mean `autostart.sh`: http://wiki.openelec.tv/index.php/Autostart.sh Anyway, that should work. One way or another this won't be hard so no worries. – goldilocks Mar 21 '15 at 01:07
  • That's right! Well, I haven't got access to that Pi anymore, so I hope it is using cache smartly :D Anyway, reads are much less stressful than writes as you mention – whitenoisedb Mar 23 '15 at 16:39