I’m planning to run headless DietPi as lite as possible on either a RPI or another similar board as a home automation server (Web server + Modbus Master + a few GPIOs).
The system will be running 24/7 and probably won’t have power backup or soft shutdown implemented so it will need to use DietPi-RAMlog #1.
I have a few questions that i can’t find a direct or up to date answer in the forum.
From what i read in the documentation RAMlog #1 keeps all the system log writes to RAM and after an hour it erases them. Are there any other frequent logs or other writes that a freshly installed Diet Pi does (no extra software or programs) that RAMlog doesn’t prevent?
How does RAMlog compare to overlayfs in terms of SD Card wear prevention or power loss protection (again taking into account a freshly installed DietPi without extra software)? Though for convenience/complexity reasons i would prefer to avoid using a custom overlay file system.
Anyone has any experience of SD Card expected lifetime while using DietPi with RAMlog #1 in similar headless server situations.
From what i understand if RAMlog #1 prevents all the system writes and i also keep my writes to a minimum (a few sensor data every 10 minutes on a txt) then the system will be quite safe both in terms of SD Card wear prevention or power failure protection?
Thank you for your time and for your effort in this awesome OS.
The RAMlog feature covers /var/log only as it will apply a tmpfs. It did not protect the system for any other disk r/w operation.
The service life of an SD card depends heavily on usage and how much I/O is generated. The quality also plays a decisive role. The cheaper an SD card is, the higher the risk of failure. If your SBC offers the option of booting from USB, you should perhaps consider a USB device or an SSD.
It sounds like it will be preferable to go with either a USB boot capable SBC or even an SBC with eMMC.
I might sound paranoid but since i can’t totally avoid the corruption case i’d rather minimize that chance.
I’m still a bit curious about expected lifetime of SD Cards running such minimal systems if people could share their experience even though i understand that nothing is guarantied and every case will be different.
On RPi device, you could have a look to RasPiKey. It’s an eMMC Module for Raspberry Pi SBC. The solution is not cheap but works quite well in RPI SBC and can be used easily via the SD card slot.
You can take into account that writing the same file on SD Cards do not write the same flash memory location (it is organised i a kind of ring buffer type).
If you e.g select a 32 GB card and your system needs typically less than 8 GB in smaller applications, the remaining 24 GB are used to cover write acesses to files.
Normally this lasts a long time until the SD Card lifetime will be reached. I think there are zillions of calculations about this “googleable”.
Main topic is to buy high quality SD Cards (same applies if you use USB sticks).
has any of the devs taken a look at the log2ram scripting over at github?
Log2Ram
Log2Ram works just like ramlog for systemd (on Debian 8 Jessie for example).
Useful for RaspberryPi for not writing on the SD card all the time. You need it because your SD card doesn’t want to suffer anymore!
Explanations: The script creates a /var/log mount point in RAM. So any writing of the log to the /var/log folder will not actually be written to disk (in this case to the SD card on a Raspberry Pi) but directly to RAM. By default, every day the CRON will synchronize the contents in RAM with the folder located on the physical disk. The script will also make this copy of RAM to disk in case of machine shutdowns (but, of course, it still won’t do it in case of power failures). This way you can avoid excessive writing on the SD card and extend its life.
Log2Ram’s script works on every Linux system. If you don’t have Systemd, you can still use Log2Ram with your own daemon manager.
Log2Ram is based on transient /var/log for Systemd. For more information, check here.
I mean I don’t understand why all SBC distro’s don’t script ramlog and zram default…even with some of the higher RAM boards out…zram and ramlog to reduce writing to SD/EMMC/USB/SDD (non spinning hardware) is kind of a no brainer…stock…default…running out of the box (I mean a swap file/swap partition on a SD card is just kinds dumb), now for stuff installed on older PC x86 systems sure…regular logs/writing to drive is ok…but writing to devices that wear out due to writes should be “the standard”
Is it standard though?
zram should be the standard for SBC’s…no swap file or partition…the OS has swap but doesn’t write to a wearable device
But pretty darn cool that it’s included!..Awesome!