Raspberry Pi: Extending the life of the SD card
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
- 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.
- 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.
- 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.
- 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
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.