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
- Be sure your Pi isn’t using the SD card for swap space.
- 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:
/tmp
/var/spool/rsyslog/
(if you use rsyslog)- Any application-specific temp files1
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 a shorter interval (
daily
instead ofweekly
) - Keep fewer historical files around (
rotate 1
) - Rotate based on file size instead of time (
size 1M
) - Use
compress
(ordelaycompress
if needed)
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:
- Move it entirely to RAM with a
tmpfs
, as described in my read-only filesystem post - 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):
- Add the option
,commit=900
, which tells the system only to flush writes to the SD card every 900 seconds (15 minutes)- Obviously, this comes with a risk of losing up to 15 minutes of data due to a crash or power outage. If that’s not acceptable, change the commit time accordingly.
- If it’s not there already, add the
,noatime
option to the/
mount
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.
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 uptmpfs
mounts for directories specific to your use case. ↩