Did Log2ram Actually Reduce Writes on Your Host?

Did Log2ram Actually Reduce Writes on Your Host?

The checks I would make before calling a logging tweak successful

Between the Clouds Newsletter

Nov 2

One of the things that is easy to do in the home lab is install a tool, then see that the service is running, and just move on to the next project. I have been using Log2ram in my Proxmox VE Server cluster home lab to help to reduce log writes. But there is another part of this tweak that needs a look. How do you know whether it actually made much difference on your host? A running service tells us that something started. It doesn’t tell us how many log writes we have taken away from the SSD.

First, make sure the logs are going to RAM

One of the first things that I check is to make sure the logs are now targeting RAM as their first location. You can find that out with the following command:

findmnt -T /var/log

For a typical Log2ram setup, you will see a tmpfs mount like the above. This means the directory is backed by your RAM and not a disk location. If you still see your normal root filesystem, go back and check the installation before trying to measure a benefit.

Also, take a look at the service logs:

journalctl -u log2ram -b --no-pager

Look for startup or other errors. Make sure the RAM you have configured has room for your logs to grow. A setup that works right at first after a cleanup may run out of space once normal logging resumes.

Compare a normal day with another normal day

This is the test that you need to do as well after having some time with Log2ram running. First, take note of the drive’s write counter before making the change. For an NVMe drive, you can use something like:

smartctl -a /dev/nvme0

Use your actual device name and record the Data Units Written value. Then, note the date and time. Check it again about 24 hours later. The difference is what the drive received during that period. Take note of that value.

Then, after enabling Log2ram, repeat that same check over another day of activity. Start the second measurement after the installation and a reboot.

For example, say your drive received 30 GB during the first day and 22 GB during the second. These are example numbers, not results from my lab. That is an 8 GB difference. Before giving Log2ram all the credit, ask what else happened. Did you run the same VMs? Was there a backup, an update, or a large download on one day?

If the days were very different, take another sample. Don’t stop your normal workloads just to get a better number.

Writing back the logs to disk

Log2ram copies logs back to disk at a certain scheduled time. So, making the check during a quiet ten-minute window can make the difference look bigger than it is. Be sure to include the scheduled synchronization in your values you record. If you changed its schedule, use a window that covers that schedule.

Also, if your boot SSD holds your VM disks, the counter includes the hypervisor’s activity too. A database that is chatty can easily hide a smaller reduction in host logging. This doesn’t mean Log2ram didn’t make any difference. It means logging may not have been the biggest writer on that drive.

I would rather find that out than keep adding tweaks without knowing which workload needs attention.

Keep the logs you still need

The thing to note is that logs that aren’t written to disk are lost let’s say if you have a host crash or unexpected power event. Keep this in mind as a con of using something like Log2ram.

Check out my full post on the tweaks you can make to help reduce the writes to your Proxmox SSD and overall, help to improve its lifespan here: https://www.virtualizationhowto.com/2026/10/5-home-lab-projects-to-try-this-weekend-october-30-2026/

© 2026 Brandon Lee
548 Market Street PMB 72296, San Francisco, CA 94104