Raspberry Pi: Extending the life of the SD card

Raspberry Pi: Extending the life of the SD card

Summary: SD cards are said to have a finite life. If you are planning on running a Raspberry Pi 24x7x365, there are some steps that you can take with GNU/Linux to extend the life of the card: here are some ideas.


Recently I posted about how I believe that the Raspberry Pi is the perfect small server.  One question came up about the SD storage. SD cards are said to have a finite amount of writes that are possible, before they start to fail.

Is this an issue when using the Pi as a server? It could be, even though posts about SD card failures are scattered but not entirely conclusive. I started to look at ways to minimize the number of writes to the SD card, which in theory should help extend its life.

 Best Practices for running GNU/Linux on an SD card

  1. Get a larger card. Writes are supposed to be spread out among the card, so the larger the card, the less chance of it writing over the same area multiple times. Most GNU/Linux distributions on the Pi can fit on a 4GB card, but 8GB and even 16GB cards are becoming more affordable. Just going from a 4GB to 8 GB card will cut the number of writes to the same area of the card in half.
  2. Stick with name brands. There are a lot of posts that mention sticking to top brands. I didn't compile a list nor do I endorse any specific brands, but fortunately there are enough posts out there that show the top brands and their failure rates.
  3. Tweak GNU/Linux to write to RAM instead of the SD card. This uses a feature called "tmpfs", which a really cool feature of GNU/Linux. Tmpfs can write to RAM as if it was an ordinary filesystem. It's fast, efficient, and easy to use. More details on that below.
  4. Set the SD card to read-only mode. This essentially makes GNU/Linux run in read-only mode, similar to how it works booting from a Live CD. This avoids any writing to the SD card and in theory can extend its life. There are some drawbacks to this though. First, it takes a bit of work to set up, which is out of the scope of this article. Second, changes that are made will be lost when the system is rebooted because they are not written to the SD card. To me, running GNU/Linux in read-only mode is overkill and I don't recommend going to this extreme.

Using Tmpfs

As I mentioned, tmpfs can write to RAM instead of the local disk (in this case, the SD card). Using it is simple. All that needs to be done is add an entry to the /etc/fstab file (to mount the folder you wish to have written to RAM) and reboot (so that each mount is cleanly mounted before services start writing files). 

The kernel will do the rest for you by managing the writes to the RAM on this virtual filesystem. The really neat part about this is that the kernel will only use the amount of RAM required for writing files, not the entire size of the mount. So, for example, say we add this line to the /etc/fstab file:

tmpfs   /var/log    tmpfs    defaults,noatime,nosuid,mode=0755,size=100m    0 0

The kernel will mount /var/log to RAM, however it will not use any RAM until files are written to /var/log.  When files are written to /var/log, the kernel will save them to RAM and only use space to save the files.  When files are removed from /var/log, the associated RAM to store them is freed up. 

This means that it only uses what RAM it needs to in order to store the files, which makes it very efficient.

In /etc/fstab, you can also specify the total size to allocate for each mount. In the example above, we set "size=100m" so that /var/log can use up to 100 MB of space and no more. This avoids a filesystem from using up all of the RAM which can cause the system to slow down or even crash. By running the "mount" command, we can see in the example above that /var/log is mounted as a tmpfs volume to RAM, 100 MB in size.

Filesystem            Size  Used Avail Use% Mounted on
tmpfs                 100M  596K  100M   1% /var/log

There are a variety of locations that GNU/Linux likes to make frequent writes. This is a list of entries below that I use as a starting point that should fit for most distributions.

tmpfs    /tmp    tmpfs    defaults,noatime,nosuid,size=100m    0 0
tmpfs    /var/tmp    tmpfs    defaults,noatime,nosuid,size=30m    0 0
tmpfs    /var/log    tmpfs    defaults,noatime,nosuid,mode=0755,size=100m    0 0
tmpfs    /var/run    tmpfs    defaults,noatime,nosuid,mode=0755,size=2m    0 0
tmpfs    /var/spool/mqueue    tmpfs    defaults,noatime,nosuid,mode=0700,gid=12,size=30m    0 0

Raspberry Pi: 11 reasons why it's the perfect small server

Raspberry Pi: 11 reasons why it's the perfect small server

Raspberry Pi: 11 reasons why it's the perfect small server

As you can see I make use of the "size=" parameter to avoid using up huge amounts of RAM in case something tries to save a huge amount of data. The "noatime" and "nosuid" parameters are also recommended for security and performance, and "mode=" along with "gid=" matches the permissions and group of the original filesystem to what was located on the SD card originally. 

Yep, tmpfs can also handle permissions. As usual, entries in /etc/fstab mount over the top of what is on the SD card, as standard Unix/Linux types do. So if for some reason the mounts fail, writes will still work to the SD card.

One additional point to keep in mind is that anything mounted with tmpfs will be lost on a reboot. So, logs in /var/log in the example above will be wiped out if the computer is shut down or rebooted. So you will not want to save any files with tmpfs that need to be persistent among reboots.

I'm actively using these settings and so far having great results. Time will tell how the Pi and/or SD card hold up, but there are a lot of posts out there with some great uptimes, as we know GNU/Linux itself doesn't need frequent rebooting like other operating systems.  The steps above should hopefully hold up, especially if you intend to run the Pi 24x7x365.

Further reading

Topic: Linux

Chris Clay

About Chris Clay

After administering Linux and Windows for over 17 years in multiple environments, my focus of this blog is to document my adventures in both operating systems to compare the two against each other. Past and present experiences have shown me that Linux can replace Windows and succeed in a vast variety of environments. Linux has proven itself many times over in the datacentre and is more than capable for the desktop.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Root filesystem on USB stick

    There are plenty of tutorials out there for this. Boot from SD but use a USB pen drive for your filesystem. Massive performance boost and far more stable.
    • LAN > USB

      USB sticks will eventually run in to the same issue. However the PI's firmware will allow it to boot from the SD Card and then mount via NFS it's partitions.

      This also frees up a USB port. People are unlikely to run the Pi without a LAN attached so doing this makes sense.
  • Re: Root filesystem on USB stick


    There's definitely some controversy on SD vs. USB, but even USB sticks use flash technology so it too has a finite number of writes. There are also posts on using a spinning external USB drive as well, which some may prefer.

    In the case of the Pi though, only having two USB ports can be limiting (unless using a powered USB hub) so using the SD slot can be desirable vs. tying up a USB port. But, as always it depends on what it's being used for.

    Thanks for your comments and thoughts!
  • Boot to server drive

    While it is true that you must have an SD card to start the boot process on an R Pi, you do NOT have to run Linux from the card. If you are using it as a server, then you obviously have an external USB drive. Just create an 8gb ext4 partition on that drive and use the dd command to copy the ext partition on the SD card to that partition. The edit the config.txt file in the SD card's fat partition to point to the new partition instead of the SD card ext partiton. The boot process will then read the config.txt file and switch immediately to the new USB partition. NO writing will be done to the SD card.
    • Definitely an alternative


      Some good thoughts there. While my focus was to avoid any extra peripherals if possible and keep costs down and simplicity up, that is definitely a good idea. A good case is running software that needs to make frequent writes and for them to be persistent writes (remain after a reboot). Using network storage like iSCSI, NFS, CIFS (since GNU/Linux can all of these) might be a good option in some cases. I would be really interested to hear if anybody tried this out.