Should I be concerned about SD card/onboard flash lifespan running Linux?

[charlieholimex]

Doesn't Linux do a certain amount of writing to disk all the time?

How long can I expect the NAND flash to last running Linux, assuming the application software writes small amounts of data every minute? Years? Decades?

Is the answer different if the OS is on SD card or onboard FLASH?

Are there any rules of thumb?

[tlhingan]

I've never used the NAND on these, just the SD card, and here's my 2 cents.
There are no rules of thumb as each SD card manufacturer has a different level of quality in their components. Shutting down the board through software instead of the physical power button corrupts the filesystem way less, and some SD cards have better tolerance than others to hard shutdowns (physical power button).
If it's worth anything, the SanDisk Ultra microSD cards are sh!t. They corrupt extremely fast on embedded devices. ADATA and Patriot microSD cards seem fine in my hands.

[rfk]

First off: NEVER EVER do a "hard" power down - the chance to damage SD-Card (and likely Flash) is just VERY high! Use a LiPo to survive power outage.


Currently working with the A20 board for a monitoring solution, based on nagios.


Since Dec. 22 13:30 CET (about 2.5 weeks now) I have 252.765.576 writes to the RRD's - well, of course I use a RAM-Disk, LiPo and scripts to save and load volatile data!
So lifetime in my case IS an issue.


It is not the first time for me, dealing with that issue.About 6 or 7 months ago, I received a slightly less vague response about lifetime of both, SD-Card and embedded Flash:
"Todays flash memories have an expected lifetime of approx. 3000 writes per cell"
(this comes from a BeagleBone Mod, claiming, the information came from a TI technical person)


I did some more research and found a paper from STEC (AN-0702, January 2008) they claim about 2 Mio write / erase cycles per logical block.
In the same paper, they state, due to cost reduction, latest flash technology ... 300,000 write/erase cycles per logical block! (One has to keep in mind, the difference between Cell, Page and Block)


I have to confess, all this number "games" are really confusing !


With respect to wear leveling and lifetime, the most reasonable measure seems: trust in manufacturers technology an use a 8 GB card if you need 4 GB.
Thats also the reason for me, to ignore boards with onboard flash - I want my customers happy for more than only a few months.


But possibly Olimex has a more elaborate and knowledgeable answer to this?
If so, please shed some light on this issue!

[progmetalbg]

Two tips from me:
1. Either use flash friendly file system such as F2FS or enable some parameters in /etc/fstab if you use ext4 - "noatime", "nodiratime".
2. Stop logging of daemons (syslogd / systemd's journald) directly to file system and configure them to write the logs in RAM (tmpfs).

The bad thing about flash memory is that newer chips produced with 20 nm tech and below have even less than 3000 writes per cell. However, the controllers (at least in SSDs) are smart enough to write the data to different cells.
http://www.computerweekly.com/SSD-write-endurance-Will-HPs-memristor-be-the-successor-to-flash
Note that SLC flash is used mainly in enterprise products (it is expensive) so for consumer flash based products check the MLC and TLC data in the link above

[tlhingan]

Good article!
+1

[charlieholimex]

Here's another article about running Linux on compact flash.

http://docs.oracle.com/cd/E19045-01/blade.x6440/820-3962-11/chap_CF.html

[pete_l]

My personal experience is that a RPi I implemented a 24*7 application on burned through SD cards in a few months. Some cards lasted 6 months or more. One fried itself after just 3 months.
With my A20, I put /tmp and /var/log in RAM, by having these entries in /etc/fstab

tmpfs /tmp     tmpfs defaults,noexec,nosuid,nodev,mode=0777,size=64M 0 0
ramfs /var/log tmpfs defaults,noexec,nosuid,nodev,mode=0777,size=64M 0 0

In addition to the stuff that is mounted in memory, by default.
You do have to watch the size of log files. Since this implementation is web based, I can upload the (old, compressed) log files to the server and delete them from the local board. I also have a small LiPo attached to the board. This will keep it running for 1 - 2 hours, if it loses mains power.