3 hours ago, JPsy said:

Hallo zusammen, wurde seitens unraid etwas gegen die SSD Abnutzung durch Logs & Healthchecks unternommen, oder muss man immer noch selber Hand anlegen?

Welche Logs & Checks?

Unraid schreibt Syslog auf WUnbsch auf den USB Stick. Der kann dadurch natürlich schneller Abnutzen.

(Hint: Transcend Jetflash 600 mit MLC könnte da mehr aushalten als billige Sticks mit TLC oder noch höherer Datendichte)

 

unraid selber schreibt auf die SSDs (meines Wissens) keine Logs oder so.

 

Aber Anwendungen (Docker/VM) laufen in der Regel am besten auf SSDs und diese SSDs verschleißen nun einmal mit steigender Anzahl der Schreibvorgänge. Klar könnte unraid sowas ggf, in einem Ramchache/Ramdisk zwischenlagern, aber die wären dann bei einem Crash weg. Deshalb schreibt unraid (auf Wunsch) die Syslogs eben auf den USB Stick.

 

6 minutes ago, DataCollector said:

Welche Logs & Checks?

Unraid schreibt Syslog auf WUnbsch auf den USB Stick. Der kann dadurch natürlich schneller Abnutzen.

(Hint: Transcend Jetflash 600 mit MLC könnte da mehr aushalten als billige Sticks mit TLC oder noch höherer Datendichte)

 

unraid selber schreibt auf die SSDs (meines Wissens) keine Logs oder so.

 

Aber Anwendungen (Docker/VM) laufen in der Regel am besten auf SSDs und diese SSDs verschleißen nun einmal mit steigender Anzahl der Schreibvorgänge. Klar könnte unraid sowas ggf, in einem Ramchache/Ramdisk zwischenlagern, aber die wären dann bei einem Crash weg. Deshalb schreibt unraid (auf Wunsch) die Syslogs eben auf den USB Stick.

 

 

Das Problem ist, dass die json Dateien für den Docker Healthcheck alle 5 Sekunden immer wieder mit dem fast selben Inhalt überschrieben werden. Nur der Timestamp ändert sich.

Der Bug ist auch hier beschrieben: 

 

On 1/21/2024 at 7:35 PM, kennymc.c said:

Der Bug ist auch hier beschrieben: 

das ist kein bug sondern ein "feature" ... ob das gut ist sei dahingestellt ... aber "Standard" Docker Verhalten ...

auch nicht Unraid related sondern immer so ...

 

ich für mich nutze beispielsweise (mit allen Konsequenzen)

 

 

healthcheck aus und keine logs ...

 

+ weniger writes auf meinen ssd'S

- beim Start ... wenn ein Docker nicht direkt starten will oder die App darin crasht == Docker bleibt aus

- wenn ich logs will warum ... muss ich diese wieder aktivieren ... ansonsten sehe ich nichts

 

root@AlsServerII:~# docker logs plex
Error response from daemon: configured logging driver does not support reading
root@AlsServerII:~#

 

ohne den log-driver none Eintrag ...

root@AlsServerII:~# docker logs swag
[custom-init] No custom services found, skipping...
[mod-init] Running Docker Modification Logic
[mod-init] Adding linuxserver/mods:swag-maxmind to container
[mod-init] Downloading linuxserver/mods:swag-maxmind from lscr.io
...
..
.

 

alles ganz normales Verhalten und immer eine User Entscheidung was er will ...

 

its not a bug, its a feature ...

Hallo
ist das Thema noch aktuell?
Also ich habe auch sehr viele Schreibvorgägne auf meine Cache-SSD und habe dieses Thema gefunden, ist aber von 2021.

Docker auf folder anstatt image kann ich nicht umstellen da sonst die Container nicht starten.

13 minutes ago, karola said:

ist das Thema noch aktuell?

das ist das default Docker Verhalten, also ja.

8 hours ago, enect said:

Bin durch Zufall auf dieses Thema hier gestoßen und fand es interessant. Gegenüber 2021 hab ich folgende Lösung grad am Testen und es sieht bisher gut aus. Läuft aber auch erst zwei Tage. Ich musste in meinen Docker-Container-Edits nichts einstellen. Nutzung User Scripts.

Voraussetzung ist aber, dass man bei Settings Docker von der standardmäßigen vDisk zu normalen Directory wechselt.

Einmal mit At Startup of Array: Script: Mount_Docker_RAMDisk

#!/bin/bash

# --- KONFIGURATION ---
# Nutze direkt den Pfad auf meinem System, typisch auf der NVME.
RAM_DISK_PATH="/mnt/cache/system/docker/containers"
BACKUP_DIR="/mnt/cache/system/docker/container_backup"
RAM_DISK_SIZE="512M"

# 1. DOCKER STOPPEN
echo "Stoppe Docker..."
/etc/rc.d/rc.docker stop
sleep 3

# 2. AUFRÄUMEN (Alte Fehlversuche unmounten)
umount /var/lib/docker/containers 2>/dev/null
umount "$RAM_DISK_PATH" 2>/dev/null

# 3. VERZEICHNISSE SICHERSTELLEN
mkdir -p "$BACKUP_DIR"
mkdir -p "$RAM_DISK_PATH"

# 4. RAM-DISK AUF DEN ECHTEN PFAD MOUNTEN
echo "Erstelle RAM-Disk direkt auf $RAM_DISK_PATH..."
mount -t tmpfs -o size=$RAM_DISK_SIZE tmpfs "$RAM_DISK_PATH"

# 5. BACKUP EINSPIELEN (Falls vorhanden)
if [ "$(ls -A $BACKUP_DIR)" ]; then
    echo "Lade Backup in RAM-Disk..."
    rsync -a "$BACKUP_DIR/" "$RAM_DISK_PATH/"
fi

# 6. DOCKER STARTEN
echo "Starte Docker neu..."
/etc/rc.d/rc.docker start

logger "Docker RAM-Disk: Jetzt aktiv auf $RAM_DISK_PATH"

PS: Docker muss nach Boot des Servers kurz gestoppt werden, da sonst bereits Logs/Configs den alten Weg nehmen. Nachdem die RAM Disk mount ist, wird Docker wieder eingeschalten. Stop und Neustart von Docker macht das Script eigenständig. Pfade müssen bei anderen Systemen angepasst werden.

Ram_Disk_Path überlagert den normalen Pfad und legt eine Schicht RAM drüber. Docker merkt davon nichts und denkt, dass es ganz normal auf den ursprünglichen Pfad der NVME schreibt. Es muss zwingend mit dem zweiten Script kombiniert werden, da die RAM Disk quasi alle System-Daten übernimmt, aber nicht die Anwendungsdaten unter appdata. Wenn das zweite Script fehlt, kann es nach einem Neustart passieren, dass Docker vergisst, dass die Container überhaupt existieren.

Dann mach ich noch Schedule Hourly: Script: Sync_Docker_RAMDisk

#!/bin/bash
# Sync_Docker_RAMDisk

SOURCE="/mnt/cache/system/docker/containers/"
DEST="/mnt/cache/system/docker/container_backup/"

# Dynamischer Pfad für User Scripts Plugin Log-File
LOGDIR=$(dirname "$(readlink -f "$0")")
LOGFILE="$LOGDIR/log.txt"

# Zielordner sicherstellen
mkdir -p "$DEST"
mkdir -p "$LOGDIR"

if mountpoint -q "$SOURCE"; then
	# rsync erledigt die Arbeit im Stillen
	rsync -a --delete "$SOURCE" "$DEST"
	
	# Log-Eintrag
	echo "[$(date '+%F %T')] Docker_RAM_Sync: OK" >> "$LOGFILE"

	# Log-Kürzung: Wenn > 150 Zeilen, behalte die neuesten 50
	if [[ $(wc -l < "$LOGFILE" 2>/dev/null) -gt 150 ]]; then
		tail -n 50 "$LOGFILE" > "${LOGFILE}.tmp" && mv "${LOGFILE}.tmp" "$LOGFILE"
		echo "[$(date '+%F %T')] Log gekürzt." >> "$LOGFILE"
	fi
else
	echo "[$(date '+%F %T')] Docker_RAM_Sync: FEHLER! RAM-Disk fehlt." >> "$LOGFILE"
fi

PS: Sichert die Logs stündlich auf meine NVME, falls der Server abstürtzen sollte. RAM Disk wäre dann ja weg und somit evtl auch die Config eines Containers. Bei mir mir meinen Test bisher nicht vorgekommen.

Auf meiner NVME ist jetzt deutlich mehr Ruhe.

Es gibt nen Plugin in Community Apps dass das auch macht. (in 2 Tagen seit genau einem Jahr) ^^

1 hour ago, Mainfrezzer said:

Es gibt nen Plugin in Community Apps dass das auch macht. (in 2 Tagen seit genau einem Jahr)

Oh OK. Kannst du mir bitte den Namen sagen? Wäre dann vermutlich komfortabler.

Update... habs gefunden. ja shit dann... scheint wirklich genau das selbe zu sein. dann hab ich zeit verschwendet...

Edited January 15Jan 15 by enect

1 hour ago, enect said:

Oh OK. Kannst du mir bitte den Namen sagen? Wäre dann vermutlich komfortabler.

Update... habs gefunden. ja shit dann... scheint wirklich genau das selbe zu sein. dann hab ich zeit verschwendet...

Kannst du es verlinken?

Such in CA nach "RAM-Disk for Docker logs"

2 hours ago, Bigbrother said:

Such in CA nach "RAM-Disk for Docker logs"

https://unraid.net/community/apps?q=clam#r

Nur zur Info. Hab mein Script mal hier vorsichtshalber gelöscht, weil ich einen gravierenden Nachteil gegenüber das existierende Plugin gefunden habe. Das PlugIn greift früh ein und erstellt die RAM Disk. Dann laufen auch andere Sachen fehlerfrei durch. Bei meinem gebastelten Script unter User Script entstehen Fehler in der GUI von user script. Er verliert die Zuordnung zu anderen Scripts und kann sie nicht mehr sauber verfolgen und leicht schlimmeres. Daher ist meine Lösung schrott und ich investiere keine Zeit, wenn jemand schon was funktionierndes gebastelt hat.