Make the Remote SD card read-only

YIO-Remote / remote-os

💎 Buildroot OS for YIO remote

GNU General Public License v3.0

13 stars 9 forks source link

Make the Remote SD card read-only #49

Open dakaix opened 4 years ago

dakaix commented 4 years ago

Is your feature request related to a problem? Please describe. Currently the remote mounts the /boot and / partitions as read-write and writes logs to /var/log. Over time this will cause the Micro SD card to wear out.

Describe the solution you'd like Ideally the remote would re-mount the partitions as read-only, and have the logs kept in tmpfs (i.e. volatile storage). Optionally these could also be redirected to an external syslog server.

Describe alternatives you've considered Usage of endurance micro SD cards will extend the life of the card obviously, however for the majority of the time since r/w access & logs aren't needed this seems like a wasteful use of endurance.

zehnm commented 4 years ago

I'll move this issue to the remote-os project which is responsible for the Linux system and SD card image.

zehnm commented 4 years ago

This should be coordinated with #16: for the system update we'll need to redesign the partition schema. I'd also like to split up the root partition into a read-only part and writeable /var partition.

In the meantime you can configure:

/etc/systemd/journald.conf There are plenty of options for logging, e.g. use in-memory logging if you don't need log files.
YIO configuration in config.json to disable logging

Regarding SD card endurance: the quality of SD cards differs greatly! I'm running multiple RPis 24x7 over the last 4 years with constant logging and DB access without a glitch. I might just be lucky though...

zehnm commented 3 years ago

rootfs type analysis: Benchmark site for various squashfs compression algorithms: https://quixdb.github.io/squash-benchmark/ These are single-threaded compression/decompression benchmarks, including RPi2 numbers. Since we are not space constraint but have limited CPU, the compression algorithm must be well chosen. Looks like lz4 is a good start for our use case. If the impact on boot-up time is too big, then the other option is read-only ext4.