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!
regarding SD
RockPi use emmc on some of there boards, and also offer an micro sd adapter for it.
it will stick out a couple cm’s.
if thats an issue, you could get mirco sd extention-adapters on Aliexpress and such.
OrangePi also offer emmc’s and they seem to be the same format.
maybe worth looking into.
Also, maybe look into industrial sd cards.
I have no idea if this is just BS selling talk, or if there is merit to it.
You don’t have to use a direct boot from USB…you can use SD card with boot partition and have it point the root partition mount point to USB/SSD/NVME so you don’t have to flash the EMMC or firmware of the device
I do this with all my SBC’s…leave a cheapo SD card in the SD card slot…only time it is accessed/read/written to is on an update that modifies the /boot partition, the host OS runs on external device that is usually larger and much more resillient
There is also an option in dietpi-drive_manager that will do the same thing (which should be better as they dev guys scripted it to work with DietPi distro)
Here is how I have a RPiZero2W setup…I have the USB expander board on top inside a 3D printed case…I have 2 Sandisk Ultrafit USB drives in it…one is my /root 32GB, one is my /home (64GB)
warhawk@RPiZero2:~ $ blkid
/dev/mmcblk0p1: LABEL_FATBOOT="bootfs" LABEL="bootfs" UUID="0B22-2966" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="265582b0-01"
/dev/mmcblk0p2: LABEL="rootfs" UUID="3ad7386b-e1ae-4032-ae33-0c40f5ecc4ac" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="265582b0-02"
/dev/sda1: UUID="da1a2987-69f0-45b8-8a84-18b4ef88fd61" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="primary" PARTUUID="a9917cab-5fb3-40dc-806d-1e3a119c86ec"
/dev/sdb1: LABEL="rootfs" UUID="2e85c21b-014a-481f-9699-f569465d82cb" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="primary" PARTUUID="9d981849-02a4-44be-8550-e3a3be218fee"
warhawk@RPiZero2:~ $ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 1 57.3G 0 disk
└─sda1 8:1 1 57.3G 0 part /home
sdb 8:16 1 28.7G 0 disk
└─sdb1 8:17 1 28.7G 0 part /
mmcblk0 179:0 0 14.4G 0 disk
├─mmcblk0p1 179:1 0 256M 0 part /boot
└─mmcblk0p2 179:2 0 14.2G 0 part
zram0 254:0 0 1.5G 0 disk [SWAP]
Has never let me down, even though it reads/writes at USB 2.0 speeds…still faster than trying to run the entire OS on a SD card.