Log2Ram: Extending SD Card Lifetime for Raspberry Pi LoRaWAN Gateway

My LoRaWAN gateway (“Contributing an IoT LoRaWAN Raspberry Pi RAK831 Gateway to The Things Network” is running and working great now for more than a month and it already has transmitted more than 30k messages:

Gateway Overview

Gateway Overview

This creates a lot of log entries on the micro SD card of the Raspberry Pi. To avoid writing too many times log data, I have installed Log2Ram.

By default, the Raspberry Pi uses a micro SD card as storage device. The SD card as a FLASH device is subject of ‘wear-out’: each FLASH block can only be erased and written a limited number of time, and after that it fails. The ‘wear leveling’ of the disk device will allocate and use a new flash block in that case, but after some time there are no free blocks any more and the system will fail.

A running gateway will create lots of log messages stored on the card, and I have read reports that depending on the card and card size it might fail after 6-18 months.

As most of the data written as a gateway are the Linux log files, there is a solution to reduce the number of writes to the SD card using Log2Ram. It creates the mount point /var/log in RAM, so any writes to /var/log will be written to the RAM disk. Every hour, a cron job will write the RAM disk to FLASH, or at the time of a shutdown. So this greatly reduces the stress on the SD card.

Installation and setup is easy:

lot2ram installation

log2ram installation

Go to the pi home directory:

cd /home/pi

Clone there the log2ram git repository:

git clone https://github.com/azlux/log2ram.git

Change directory to the downloaded repository folder:

cd log2ram

Make the installation script executable:

chmod +x install.sh

Install it:

sudo ./install.sh

Change the log size value to 128M:

sudo nano /etc/log2ram.conf
Log Size 128 MByte

Log Size 128 MByte

Save the file (CTRL-X, yes, ENTER), then reboot:

sudo reboot

To check if it was working, use

df -h

This should show the new disk:

log2ram disk

log2ram disk

In addition to this, check with

mount

which should show our mount point:

log2ram on /var/log type tmpfs (rw,nosuid,nodev,noexec,relatime,size=131072k,mode=755)

That’s it! With this, writing to FLASH should now be greatly reduced. Time for muffins!

Happy Logging 🙂

Links

Advertisements

18 thoughts on “Log2Ram: Extending SD Card Lifetime for Raspberry Pi LoRaWAN Gateway

    • Power outage is a very rare event in Switzerland. I power the Pi with PoE which is attached to a UPS. But I’m think about adding a small Pi UPS, that way it can shutdown the Pi with a pin. It is possible to assign a pin which can be used to power down the Linux: I’m using that already with a Kinetis K22 (tinyK22) board.

      Like

  1. Pingback: Give Your Raspberry Pi SD Card a Break: Log to RAM | Hackaday

  2. Hi Eric,

    You mention a cron job that can write the logs from RAM to SD card every hour, but I don’t see any setup for that.
    Is this something automatically set up, or it has to be defined in addition?

    Like

  3. Are you aware of any actual SD card failures in a Raspberry Pi? Statistics? I’ve had one running continuously since December 2012 with extensive logging to an 8GB card with no problems. I was persuaded to not use RasPi in a commercial product because the SD would be unreliable, but I’m not sure that’s the case with quality (SanDisk or Samsung) cards.

    Like

    • I’m running openHAB on my Raspberry Pi, and SD card failure is a big talking point in the user community. Statistics would be difficult to get, since most people just plug in a new SD without ever reporting the failure, but there are enough people claiming it that I think the risk is real. As you say, using higher-quality cards probably mitigates that risk.

      Like

  4. Howdy Erich, I just tried this on my Pi Zero W that is Running FlightRadar24 and it didn’t seem to create the mount for it. The GIT pulled and it seemed to install then reboot, then I edit the selected file but after rebooting there is not an entry under `df -h` for log2ram.

    Like

  5. Great job, this is a really good idea and perfect implementation. Thank you! I’ll have this on all my Raspberries for sure.

    Like

  6. Have a look at https://github.com/StuartIanNaylor/zram-config as it has a number of advantages over Log2Ram.

    Some problems with Log2Ram :-
    Firstly the hourly write out of logs is near pointless as its only there for a full system crash as is written on stop. Its near pointless as the log info of a unlikely full system crash is still likely to be lost unless you where fortunate enough that it happened as the hourly write had just taken place.
    Also any log that has changed gets copied in full on every hour which sort of negates it purpose and strangely its for no real reason
    Also it stores all the oldlogs in memory which isn’t required but copies all this on start again for no real reason.

    zram-config above does zswap, zram & a zlog but in a much better manner.
    It uses zram in the upper of an OverlayFS mount with the original dir in a lower bind bind so because of the copyup of COW only changes are in zram.
    The same principle is used for zdir and large directories with zero writes in extremely small memory footprints can be accomplished.
    It also uses the olddir directive of logrotate and ships oldlogs to persistant and again saves far more ram than log2ram.
    You can create any number of zswaps, zdir and a zlog via /etc/ztab and will greatly reduce sd write whilst using a much smaller memory than Log2ram and is much less likely for /var/log to hit the limit and fail as log2ram often does.

    Like

  7. I think, as the number of sectors written to the sdcard is NOT reduced by writing them at another time (e.g. delayed, grouped or whatever), the wear level doesn’t get any better.
    I think, you have to throw away data to reduce wear leveling.
    So I think, you have to disable the writes to sdcard completely or may be sent the logs to a remote syslog server or via email or similar (but don’t save a temporary file).

    Delaying and grouping writes is used to increase performance on disks where access time is significant (= hard disks). It is also useful to reduce power dissipation in some cases.

    Also, consider something like laptop-mode-tools…

    Like

    • Agreed: the less data the better. On the writes it depends how they are cached (or synced with the disk). So if there is a small amount of data, but the data is flushed/written all the time as it happens with the log files, this will greatly increase the wear of the disk.

      Like

  8. Pingback: Tutorial: MCUXpresso SDK with Linux, Part 1: Installation and Build | MCU on Eclipse

What do you think?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.