What is the lifespan of an SD card with Raspbian (Raspberry Pi)?

Question

As all Raspberry Pi users should know, operating system runs from SD card.

This can result in a problem, because if the card is written many times constantly, it will reduce SD lifespan for quite little time. If I remember correctly, Flash Memory usually has an expectation of only about 10,000 writing operations.

Well, with this I would like to know if the Raspbian makes written on the SD card even when it is idle.

And in case you have any operation, perhaps logging, how can I disable this operation that is compromising the life of SD?

I’m doing a project that will never (hopefully!) be shut down.

I already have a system with PIC microcontroller, and in this not even the EEPROM memory is being written for that reason. However, the PIC is not capable of new requests for operations.

I found an answer for Debian, but it is outdated for Raspbian:

Tips for running Linux on a flash device by David Härdeman

<[email protected]>

If you are running your NSLU2 on a USB flash key, there are a number of Things you Might want to do in order to reduce the Wear and tear on the underlying flash device (as it only Supports a Limited number of Writes).

Note: this Document Currently describes Debian etch (4.0) and needs to be updated to Debian Squeeze (6.0) and Debian wheezy (7.0). Some of the hints may still apply, but some may not.

The ext3 filesystem per default Writes Metadata changes Every five Seconds to disk. This can be increased by Mounting the root filesystem with the commit=N Parameter which Tells the kernel to delay Writes to Every N Seconds.

The kernel Writes a new atime for each file that has been read which generates one write for each read. This can be disabled by Mounting the filesystem with the noatime option.

Both of the above can be done by Adding e.g. noatime,commit=120,... to /etc/fstab. This can also be done on an already Mounted filesystem by running the command:

mount -o remount,noatime,commit=120 /

The system will run updatedb Every day which creates a database of all files on the system for use with the locate command. This will also put some stress on the filesystem, so you Might want to disable it by Adding

exit 0

Early in the /etc/cron.daily/find script. syslogd will in the default installation Sync a Lot of log files to disk directly after logging some new information. You Might want to change /etc/syslog.conf only that Every filename Starts with a - (Minus) which Means that Writes are not synced immediately (which increases the risk that some log messages are Lost if your system crashes). For example, a line such as:

kern.*                          /var/log/kern.log

would be changed to:

kern.*                          -/var/log/kern.log

You also Might want to disable some classes of messages altogether by logging them to /dev/null Instead, see syslog.conf(5) for Details.

In addition, syslogd Likes to write -- MARK -- Lines to log files Every 20 minutes to show that syslog is still running. This can be disabled by Changing SYSLOGD in /etc/default/syslogd so that it reads

SYSLOGD="-m 0"

After you’ve made any changes, you need to Restart syslogd by running

/etc/init.d/syslogd restart

If you have a swap Partition or swap file on the flash device, you Might want to move it to a Different part of the disk Every now and then to make sure that Different Parts of the disk gets hit by the Frequent Writes that it can generate. For a swap file this can be done by Creating a new swap file before you remove the old one.

If you have a swap Partition or swap file stored on the flash device, you can make sure that it is used as little as possible by Setting /proc/sys/vm/swappiness to zero.

The kernel also has a Setting known as laptop_mode, which makes it delay Writes to disk (initially intended to allow laptop Disks to spin down while not in use, Hence the name). A number of files under /proc/sys/vm/ Controls how this Works:

/proc/sys/vm/laptop_mode: How Many Serconds after a read should a writeout of changed files start (this is based on the Assumption that a read will cause an otherwise spun down disk to spin up Again).

/proc/sys/vm/dirty_writeback_centisecs: How often the kernel should check if there is "Dirty" (changed) data to write out to disk (in centiseconds).

/proc/sys/vm/dirty_expire_centisecs: How old "Dirty" data should be before the kernel considers it old enough to be Written to disk. It is in general a good idea to set this to the same value as dirty_writeback_centisecs above.

/proc/sys/vm/dirty_ratio: The Maximum amount of memory (in Percent) to be used to store Dirty data before the process that generates the data will be Forced to write it out. Setting this to a high value should not be a problem as writeouts will also occur if the system is low on memory.

/proc/sys/vm/dirty_background_ratio: The Lower amount of memory (in Percent) Where a writeout of Dirty data to disk is allowed to stop. This should be quite a bit Lower than the above dirty_ratio to allow the kernel to write out Chunks of Dirty data in one go.

All of the above kernel Parameters can be Tuned by using a custom init script, such as this example script. Store it to e.g. /etc/init.d/kernel-params, make it Executable with

chmod a+x /etc/init.d/kernel-params

and make sure it is executed by running

update-rc.d kernel-params defaults

Note: Most of These Settings reduce the number of Writes to disk by increasing memory Usage. This increases the risk for out of memory situations (which can Trigger the dreaded OOM killer in the kernel). This can Even happen when there is free memory available (for example when the kernel needs to allocate more than one contiguous page and there are only fragmented free pages available).

As with any tweaks, you are advised to Keep a close eye on the amount of free memory and Adapt the tweaks (e.g. by using Less aggressive caching and increasing the swappiness) Depending on your Workload.

Answer 1

I believe that this is very relative.

A flash memory has approximately a lifetime of 10,000 (ten thousand) to 1,000,000 (one million) writing cycles (note that this value has a very large "range"). However, this may vary greatly from manufacturer to manufacturer and may even vary with the conditions the hardware is exposed to.

It is also quite complicated to map all write operations that the operating system does (in this case, Linux) and quantify them, mainly to perform a lifetime calculation. All you talk about this is speculation, because it’s a very complex task to map out everything that’s going on in the operating system.

What you can do is rely on the lifetime of Android smartphones. The operating system is based on Linux and works quite similar to Raspbian. We also use SD cards on smartphones.

The operating system does read and write operations in a very frequent way. Remember that "everything is a file". But during startup, much of the content of these files is allocated in RAM. Rest assured, the operating system will do write operations when you install some program, make settings, create files, edit files, manipulate a database. It can also happen that the operating system does a write operation simply to change a flag or configuration of some file. It’s unpredictable to say when the system will do this, because there are thousands of programs running. And as for Raspbian being "idle", this is also very relative. Apparently he may not be running any program, but the system is running thousands of tasks that enter and exit context several times in a single second! Context inputs and outputs use RAM and processor cache, but during context input and output, RAM may be missing and the system uses SD card as virtual memory (swap), in this case we have another write operation in SD.

The question you raised was quite interesting, but I believe that there is an absolute answer, and I believe it is impossible that your Raspberry can stay "eternally connected".

Some SD card manufacturers guarantee a lifetime of 5 years. So I doubt it will last longer than this. Even if you do minimal read and write operations, an SD card is not designed to last forever, especially when it is constantly connected. There are numerous factors that cause decreased service life like humidity, heat, light and even programmed obsolescence! Because SD cards have an internal microcontroller, responsible for making SPI-type communication, therefore it may have been easily programmed to after a number of read/write operations be totally useless.

I recommend that you check with the manufacturer for the life period of the card, avoid doing too many writing operations, mapping some of the points I mentioned, and do not wait much longer than 5 years for your SD card. It is possible to remove operating system logs and thousands of other things that might be writing on the card, but the system was designed this way and this can cause malfunction and lock your application, besides being a difficult task, because you will have to make many modifications in several files.

Edited:

I found this article containing some real tips on how to increase the life of your SD card with Raspbian. The one that most caught my attention was: "Put the SD card as read only", so there is a hardware level guarantee that your card will not be written. However, as the author himself states, there are some disadvantages and it takes a lot of work to configure the Operating System to work this way. In addition, all changes the system makes cannot be saved.

I suggest you buy an SD card from a known brand with a very large transfer rate (a class 10 is already a good one), because regardless of the life time of the card, your Raspbian will work better. And buying a card with a larger amount of storage (Raspbian only supports up to 32Gb) will increase the life period as there will be a larger area to be written.

Another important tip I read on article is to use "tmpfs", which is a feature that lets you write to RAM as if it were a common filesystem. With this you will save on the writings in SD, what you can do (see that this is just a speculation) with which the useful life increases. Be careful with this feature, calculate which programs will be run and don’t leave the system without space in RAM.

Answer 2

In short: don’t bother with this.

The 10,000 or 100,000 write operations count per 512-byte cell, but the SD card circuit itself switches the use of cells so that they all "spend" equally. In addition, these are the minimum guarantees -- most cells last much longer and good brand cards have backup cells to compensate for the first failures.

This translates into a very long lifespan, probably longer than a hard drive. The card will spoil for "natural causes" (for unless it is used, USB stick or SD card seems not to last more than 5 years as it is very sensitive to static or even a good tumble) or more likely you will exchange it for a larger card.

The only possible exception is if you are running a program that records data at full speed all the time. Still, it will take time. Recording 8GB for 100,000 times will take months, this is 800TB. What use case generates so much data?

If you really want to "flip":

1) Unix/Linux records (writes) the last READ date of a file. Mounting the file system with "noatime" prevents this recording, which relieves SD Card and is almost always indicated in embedded systems for performance reasons. In the past it was customary to do this even on home Linux. Probably the Linux distribution you use for Rasbpberry already does this.

2) The SD card brand makes a difference. If you want a lot of reliability, buy from good brands.

3) Use a larger SD card, dividing the wear between more cells. Only worth it if you really expect to record a lot of data all the time e.g. the Raspberry controlling surveillance cameras, or using a lot of swap.

Answer 3

I found another suggested installation in read-only system, but also not for Raspbian, maybe this can serve as an example for someone to contribute some hint oriented to Raspbian:

Howto: Install readonly emdebian on NAND
(http://forum.doozan.com/read.php?2,72)

I've done some preliminary work getting debian installed to the NAND:

The installation is, by default, readonly. The installer includes a few workarounds to make everything work from the readonly filesystem. It creates a /sbin/init-ro script to mount and initialize a few tmpfs mount points. My goal is to keep the root system readonly, with all read-write parts located on tmpfs, NFS, or external drive.

You can add extra packages by modifying the variables at the top of the installer, or by remounting the system read-write and running apt. By default, this install will only install packages from embdebian. If you need to install packages from the full Debian, you'll need to add a repository to /etc/apt/sources.list. Be aware, however, that the package list itself is over 30M.

If you would prefer to make it read-write, just 'mount -o remount,rw'. You can edit /etc/fstab and remove the 'ro' from the root mount make the system permanently read-write.

The default install is 112M uncompressed on ext2 and 72M compressed on UBIFS.

I welcome any comments and suggestions on improving this.

-- Jeff

Remove USB drive, boot into pogoplug
Attach your USB drive, partition it with fdisk, and then run the following commands: 


cd /tmp
wget http://jeff.doozan.com/debian/dockstar.emdebian-squeeze-readonly.sh
chmod +x dockstar.emdebian-squeeze-readonly.sh
export PATH=$PATH:/usr/sbin:/sbin
./dockstar.emdebian-squeeze-readonly.sh


Reboot into Debian
Create UBIFS on mtd3 using the following commands: 


flash_eraseall /dev/mtd3
ubiformat /dev/mtd3 -y
ubiattach /dev/ubi_ctrl -m 3
ubimkvol /dev/ubi0 -m -N rootfs


Copy system to ubifs 


mkdir /tmp/ubifs
mount -t ubifs ubi0:rootfs /tmp/ubifs

tar \
--exclude=/lost+found  \
--exclude=/tmp  \
--exclude=/sys  \
--exclude=/proc \
-cf - / | ( cd /tmp/ubifs ; tar -xpvf - )
mkdir /tmp/ubifs/tmp
mkdir /tmp/ubifs/sys
mkdir /tmp/ubifs/proc

# change root fs type from ext2 to ubifs
sed -i 's/^\(\/dev\/root.*\)ext2/\1ubifs/' /tmp/ubifs/etc/fstab > /dev/null 2>&1
umount /tmp/ubifs


Configure UBIFS booting 


fw_setenv set_bootargs_ubi 'setenv bootargs console=$console ubi.mtd=3 root=ubi0:rootfs rootfstype=ubifs $mtdparts init=/sbin/init-ro'
fw_setenv bootcmd_ubi 'run set_bootargs_ubi; ubi part data; ubifsmount rootfs; ubifsload 0x800000 /boot/uImage; ubifsload 0x1100000 /boot/uInitrd; bootm 0x800000 0x1100000'

# Configure new bootloader to run old uBoot
fw_setenv bootcmd 'run bootcmd_ubi; run bootcmd_usb; run bootcmd_pogo; reset'


Remove your USB drive and reboot into Debian on NAND


NOTE: If you change your UBIFS root to read-only (to edit files or install packages) and lose power or crash before you remount it a read-only, uBoot will think the partition has errors and will refuse to boot from it. In that case, it will try booting from USB. If there are no bootable USB devices, it will boot the original Pogoplug installation. From there, you can mount and unmount the UBIFS partition, just to reset the 'dirty' flags and uBoot will be okay again.