Most of my projects don’t need to save any data to sd card and as far as I understand SD card can be corrupted when Raspberry Pi (or any other board) is unsafely shut down during a write.
I recently found this article which describes how to make Raspberry Pi filesystem read-only, which would make it safe to just turn off the power and the SD card wouldn’t be corrupted: https://hallard.me/raspberry-pi-read-only/
Would it be possible to configure BalenaOS in the same way so it would not write anything to SD card?
BalenaOS already mounts he vast majority of its partitions in read-only mode exactly for this reason. There is still a portion of it that is mounted read-write as its required for the Balena Supervisor to do its job. So in summary, all partitions that can be read-only are already read-only in BalenaOS!
@jviotti
So what is it writing apart from updates?
Would it be possible to disable local logging (write all logs remotely or lose them), so then RPi would only be vulnerable to SD card corruption during image or supervisor updates.
Application logs (which is the standard output) are also just kept in memory by the container engine and sent to the API to be displayed in the dashboard. Thus if you don’t keep any other logs inside the container (meaning: don’t log in the container’s file system, which is kept on disk by the container engine, while the container is running) nor the attached volumes (which is kept as long as you keep the volumes), then all the data is indeed just memory.
Anything else is missing, that we might have not covered?
We take SD card wear very seriously, and trying to reduce as much as possible.
@imrehg Thanks, didn’t know that you were already sending all of the logs to your api, that’s great news!
So, am I correct to assume that if I’m not performing an application or supervisor update it’s safe to just power off the RPI since nothing is being written to SD card?
It is pretty much always safe to power off the device. balenaEngine does sync to the disk directly as it pulls any image (as opposed to docker/moby, which pulls to memory first), and unless the whole of the image arrived it won’t be used.
You can run your own tests, of course, but in our experience the devices should be safe pretty much all the time even in the face of power loss. (This not counting application data, e.g. if your application writes anything to disk, or need to exit cleanly)