Chris Dzombak

sharing preview • dzombak.com

Pi Reliability: Reduce writes to your SD card

If you aren't using a read-only filesystem on your Pi, you can still reduce writes to the SD card to increase its lifespan.

Pi Reliability: Reduce writes to your SD card

Part of the Raspberry Pi Reliability series.

If you aren’t using a read-only filesystem on your Raspberry Pi, you should reduce the amount of stuff that gets written to its SD card. This will help increase the card’s lifespan and keep your Pi running smoothly.

Caution: Advice to avoid

This Stack Exchange post suggests disabling journaling for the Pi’s filesystem. Don’t do this. While this change might reduce SD card wear, it makes your Pi more likely to face filesystem corruption in the event of a crash or power outage.

The changes outlined in this post are not without risk, and you should only use any given intervention if you understand what it will do. (See my Pi Reliability post on risk vs. benefits.)

Disable unneeded software and SD card swap

  1. Be sure your Pi isn’t using the SD card for swap space.
  2. Look at the services running on the Pi and disable anything you don’t need.

Migrate as much as possible to tmpfs

We want the following to be stored in RAM using tmpfs, not on the SD card:

Run mount first, along with cat /etc/fstab, to check which folders might already be in a tmpfs.

Armbian, for example, puts /tmp in RAM by default, while Raspberry Pi OS does not.

Edit /etc/fstab and add the following line:

tmpfs  /tmp  tmpfs  defaults,noatime,nosuid,nodev  0  0

This Stack Exchange thread notes that /var/tmp shouldn't be discarded on reboots, and I don't see much there on any of my Pis, so I've opted to leave it on the SD card.

You could opt to use a tmpfs for it, too, if you'd like.

For /var/spool/rsyslog, see my remote logging guide.

Reduce logging to /var/log

Find the largest files in /var/log via:

sudo du -hs /var/log/* | sort -rh | head -n 5

Working from a list of the largest logs, reduce or disable logging for the relevant services. This is particularly important if you opt to write logs to disk; less so if you log only to RAM.

Reduce maximum journald storage usage

Whether you decide to put /var/log in a tmpfs or use log2ram, you’ll want to limit the amount of space journald tries to use. To do that, edit /etc/systemd/journald.conf. Uncomment the SystemMaxUse=... line (if necessary), and set it to something around 20 MB:

#  This file is part of systemd.
# <output snipped by cdzombak>
# See journald.conf(5) for details.

[Journal]
# <output snipped by cdzombak>
SystemMaxUse=20M
# <output snipped by cdzombak>

Customize log rotation

Guided by whichever services seem to be writing large files in /var/log and which ones appear to keep a lot of history there, customize your logrotate configuration to rotate those services’ logs and/or keep fewer historial log files. As with the previous few steps, the goal is to reduce the size /var/log can grow to, ensuring its contents can fit happily in RAM.

A full logrotate tutorial is beyond the scope of this post, but happily it’s not a complicated tool. This tutorial is a good starting point, and the tool’s documentation is easy to understand.

Some specific things I commonly tweak when using logrotate to reduce /var/log space usage by a given service:

Use RAM for /var/log

On Raspberry Pi OS, /var/log is one of the biggest culprits for SD card wear. To deal with this, you can either:

  1. Move it entirely to RAM with a tmpfs, as described in my read-only filesystem post
  2. Use log2ram to log to RAM and occasionally flush to disk, as detailed in the next section.

Armbian (an alternative to Raspberry Pi OS) already uses something like `log2ram` by default; logs are written to RAM and only flushed to the SD card occasionally.

You can skip the rest of this section if your device is running Armbian.

Reduce the size of /var/log

If you plan to use log2ram, which will keep logs in RAM and occasionally sync them to disk, you should get the size of /var/log under 40MB. This size limit can be increased, but that’s not ideal, especially on something like a Pi Zero with limited RAM.

One easy way to remove (some) historical logs:

sudo rm /var/log/*.1 /var/log/*.gz /var/log/apt/*.gz

Installing log2ram

In the following commands, replace bookworm by the name of the Raspberry Pi OS version your Pi is running. Use lsb_release -a` to find this; for example, this is from one of my Pis:

$ lsb_release -a | grep -i codename
No LSB modules are available.
Codename:	bookworm

To install log2ram:

echo "deb [signed-by=/usr/share/keyrings/azlux-archive-keyring.gpg] http://packages.azlux.fr/debian/ bookworm main" | sudo tee /etc/apt/sources.list.d/azlux.list
sudo wget -O /usr/share/keyrings/azlux-archive-keyring.gpg  https://azlux.fr/repo.gpg
sudo apt update
sudo apt install log2ram

Reboot the Pi. Then verify it’s working, per the documentation. These commands will tell you whether log2ram is running and show its logs:

sudo systemctl status log2ram
sudo journalctl -u log2ram -e

And these commands will allow you to see that the log2ram mount is setup correctly. Sample output from one of my Pis is included:

$ df -h | grep log2ram
log2ram          40M  532K   40M   2% /var/log

$ mount | grep log2ram
log2ram on /var/log type tmpfs (rw,nosuid,nodev,noexec,relatime,size=40960k,mode=755)

Modify fstab options for your root partition (/)

Edit /etc/fstab again. This time, change the lines that refer to your SD card. In column 4, after the word defaults (but without adding any whitespace):

Enforce a filesystem check on every boot

On my Pis, unless a fast startup process is absolutely critical, I like to run fsck on every boot, so SD card problems will be caught early (and repairable issues can be repaired).

Run mount | grep "on / " to get the name of the device containing your root filesystem. In this sample output, it’s mmcblk0p1:

$ mount | grep "on / "
/dev/mmcblk0p1 on / type ext4 (rw,noatime,errors=remount-ro,commit=600)

Then, run sudo tune2fs -c 1 /dev/mmcblk0p1, replacing mmcblk0p1 with the name you found above.

To verify that this worked, run cat /etc/fstab, and verify that the root filesystem has a positive integer in the sixth (last) column.

References and Acknowledgements

See the notes on my earlier post.


See Also: Considerations for a long-running Raspberry Pi.

  1. I can’t help you with the files specific to your Raspberry Pi application, but you should be able to follow the fstab patterns shown here to set up tmpfs mounts for directories specific to your use case.