Containers and tmpfs

Product support balenaOS
1

We are looking to minimize wear on our SD card because currently we are logging to a shared persistent volume. Ideally we would like to keep logging these messages, but some of them are not important to survive after the device reboots. Sending the unimportant logs to a file in a tmpfs location seems like a good solution to my knowledge. The only downside I can see is that this cannot be shared between the services.

I’ve seen some posts on using a tmpfs volume in our docker-compose.yml file, here, but wasn’t sure if this is the best option after seeing the existing tmpfs mounts in the container. Is it better to create our own tmpfs volume or can I use an existing one? Also wanted to see if there is any more information about the inconsistent behavior of the /tmp directory mentioned here. This behavior seems to still apply with the small amount of testing I have done on balenaOS 2.43.0.

Thanks!

1 Like
3

Hi @ejohnso49,

Is it better to create our own tmpfs volume or can I use an existing one?

What do you mean by an existing one?
I believe it’s fine to create and manage your own tmpfs volume so you have full control over it.

Actually, there might be an alternative solution for your problem. Have you considered streaming the logs to cloud / outside of the device?

You can subscribe to the logs for a device. Here’s relevant documentation: Interacting with the balena Supervisor - Balena Documentation

There is also a forum thread where my teammate explains it further.

Btw, our in-house developed balenaFin addresses this SD card wear issue as explained in this blog post. Maybe you’d find it attractive to consider addressing your problem as well.

We are tracking that inconsistent behaviour of the /tmp directory in our internal system. I took your interest in that as well so we could update this thread when there is progress. I also asked internally to see if we have any plans to resolve it anytime soon.

Cheers…

5

Running df -h it appears that there are several existing tmpfs mounts in the container already. At least for my case, I’m using an Alpine container so I see:

bash-5.0$ df -h
Filesystem                Size      Used Available Use% Mounted on
none                     28.8G      2.3G     25.0G   8% /
tmpfs                   487.8M         0    487.8M   0% /sys/fs/cgroup
tmpfs                   487.8M      4.0K    487.8M   0% /tmp/balena
tmpfs                   487.8M      4.0K    487.8M   0% /tmp/resin
/dev/mmcblk0p6           28.8G      2.3G     25.0G   8% /etc/hosts
shm                      64.0M         0     64.0M   0% /dev/shm
/dev/mmcblk0p6           28.8G      2.3G     25.0G   8% /etc/resolv.conf
/dev/mmcblk0p6           28.8G      2.3G     25.0G   8% /etc/hostname
/dev/mmcblk0p6           28.8G      2.3G     25.0G   8% /var/log/device
/dev/mmcblk0p6           28.8G      2.3G     25.0G   8% /usr/share/device
/dev/mmcblk0p6           28.8G      2.3G     25.0G   8% /var/lib/device
/dev/mmcblk0p6           28.8G      2.3G     25.0G   8% /var/locks/device
none                    480.3M         0    480.3M   0% /dev
tmpfs                    97.6M     60.0K     97.5M   0% /run

So I was thinking that it’s not required to create a new tmpfs volume and instead use something like a subdirectory in /run. I think my purpose for this is kind of screwy and I need to rethink what my I’m trying to accomplish.

My end goal is to save important events to persistent storage so that we always have record of these events, regardless if the device lacks network connectivity and say experiences a reboot before reconnecting. Other less important messages can be sent when possible and it’s okay if they are lost during a reboot. This more so has to do with the way we monitor our logging output, which needs improvement for sure.

6

Hey, that is expected. You probably want to create your own volume to have full control over it though. Let us know if you run into any issues with this.