Haltbarkeit SD-Karte mit FHEM-Nutzung & Smart-Home?

[Waldmensch]

Ich ziehe das mounten über die fstab grundsätzlich vor. Entweder stell ich mich mit autofs zu bräsig an oder es ist wirklich fragil. Bei mir hat es bisher nur Probleme bereitet. Meist war der Mount nicht da wenn er da sein sollte, oder er war weg wenn man es nicht erwartet hat. Das Resultat ist immer dasselbe, das letztlich auf den mountpoint im lokalen FS geschrieben wurde. Ist mir über die fstab noch nie passiert, solange das Share serverseitig verfügbar war


Gesendet von iPhone mit Tapatalk

[claudio-fhem]

Der NFS-share wird ja grundsätzlich über ein Verzeichnis gemountet, warum nicht über das Originalverzeichnis von fhem?
Solange das NAS nicht gemountet ist, schreibt fhem auf die SD-KArte, sobald der mount steht, auf das NAS.

Was mit Daten passiert, die geschreiben werden sollen, während des mountens: Keine Ahnung :-D

[Dracolein]

Ich habs nun in Kombination hinbekommen
a.) in der raspi-config den Bootvorgang gestoppt, bis eine aktive Netzwerkverbindung vorhanden ist
b.) in der fstab

Code Auswählen Erweitern

192.168.178.10:/volume1/raspiaufds /synology/raspiaufds nfs rw,sync,hard,intr,x-systemd.automount 0 0
eingetragen, womit es funktioniert. Mit den parametern "defaults" o.ä. lief nichts.

Wie gesagt ist das ein gemounteter pfad ausserhalb der fhem Ordnerstruktur, wohin ich derzeit ausschließlich meine wenigen filelog-Logfiles schreiben lasse.

Der NFS-share wird ja grundsätzlich über ein Verzeichnis gemountet, warum nicht über das Originalverzeichnis von fhem?
Solange das NAS nicht gemountet ist, schreibt fhem auf die SD-KArte, sobald der mount steht, auf das NAS.

Was mit Daten passiert, die geschreiben werden sollen, während des mountens: Keine Ahnung :-D

ist ein interessanter Ansatz. So würde auch ein mount-fail-Problem verhindert werden, weil fhem den Fehler gar nicht spürt.
Aber wie prüft man dann, ob derzeit gemountet ist, oder nicht?

[Waldmensch]

Man könnte das Vorhandensein einer Datei überprüfen, die es nur auf dem Share gibt. Zum Beispiel eine Datei mit touch /mein/share/.is_share anlegen und dann mit ls /mein/share/.is_share auswerten. Wenn nicht gemounted liefert ls kein Ergebnis


Gesendet von iPhone mit Tapatalk

[Wzut]

@Dracolein , meine fstab , meine Syno hat die 0.2 :

Code Auswählen Erweitern

192.168.0.2:/volume1/logs/ /opt/fhem/log nfs rw,addr=192.168.0.2 0 0

[Dracolein]

Aber ja - warum auch nicht? Ist Unix-Standard.

LG

pah

Aus Sicht des Dateisystems habe ich keine Zweifel.

Ich dachte primär an die FHEM-Installation. Wenn wir einmal annehmen das System läuft viele Monate stabil durch (=alle aktuellen Files liegen auf dem NAS) und dann wird ein Reboot durchgeführt, bei dem das mounten des NAS minimal später passiert, als der FHEM-Start, dann greift fhem beim Systemstart zunächst auf die lokalen, völlig veralteten Files zu. Ohne tief Ahnung vom System zu haben, könnte ich mir vorstellen, dass dies massenhaft Fehler produziert

[Eisix]

Hallo,

wenn eh ein NAS da ist warum nicht gleich ganz vom Netz booten.


https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net_tutorial.md


Gruß
Eisix

[Wzut]

wenn eh ein NAS da ist warum nicht gleich ganz vom Netz booten.

das macht mein uralt RPi auf dem DoorPi läuft, eine kleine SD aus einer alten Kamera nur mit /boot Part.
Läuft so auch schon ein paar Jahre ohne Probleme.

[rudolfkoenig]

Ich hatte 4 Jahre lang FHEM auf einem Rechner betrieben, der sein Root-Filesystem und FHEM auf einem billigen 4GB USB-Stick gehabt hat.
Kaputtgegangen ist nach 4 Jahren das Mainboard.

Ich habe vorher etliche Massnahmen getroffen, damit Schreibzugriffe minimiert werden, Stichwort ist (bzw. war damals) Linux laptop mode.
Mein "HOWTO" von damals (2008):

Code Auswählen Erweitern

echo 3600   > /proc/sys/vm/laptop_mode
echo 360000 > /proc/sys/vm/dirty_writeback_centisecs
echo 360000 > /proc/sys/vm/dirty_expire_centisecs
echo 40     > /proc/sys/vm/dirty_ratio
echo 40     > /proc/sys/vm/dirty_background_ratio
Weiterhin habe ich root mit noatime gemountet, und alle Dienste abgeschaltet, die ich auf dem System nicht gebraucht habe.

Diese Einstellung hat Nachteile (z.Bsp. Datenverlust beim Stromausfall, und manche Programme kommen mit noatime nicht zurecht), die ich aber in Kauf genommen habe.

[fantalin]

Hallo,
hier wurden ja interessante Lösungen angeboten, um die Haltbarkeit einer SD-Karte zu erhöhen...
Bei meiner FHEM - Installation mit großen Log-Dateien und Log-DB's ging eine preiswerte 32GB SD nach ca. 3 Jahren kaputt.
Beim kopieren der SD mit dd traten Lesefehler auf.
Nach dem Studium einiger Heise-Artikel kaufte ich vor knapp drei Jahren die MicroSDHC-Speicherkarte 32GB, Samsung, PRO Endurance. Seitdem keine Fehler/Probleme und eine gute Performance.

Grüße
Jochen

[Sörn]

Um die Liste der Tipps noch ein wenig zu erweitern...

1) Logs in einer Ramdisk ablegen.

Ich speichere logs von FHEM und anderen Diensten (lighttpd, cron) in /mnt/logrd.

Hier ein Beispiel, wie man eine 8M große ramdisk anlegt:

Code Auswählen Erweitern

mkdir /mnt/logrd
echo 'none /mnt/logrd tmpfs nodev,nosuid,noexec,noatime,size=8M 0 0' >> /etc/fstab

8MB sind nicht viel, aber für meine Zwecke ausreichend. Ich reboote das System alle paar Monate, aber spätestens beim Kernel-upgrade. Wenn man besonders verboses debugging möchte, ist die Ramdisk nach wenigen Stunden voll. Bei mir ist's meistens level 1.

Die fhem.cfg muss natürlich auch entsprechend angepasst werden:

Code Auswählen Erweitern


attr global logfile /mnt/logrd/fhem/fhem-%Y-%m.log
attr global statefile /mnt/logrd/fhem/fhem.save
define Logfile FileLog /mnt/logrd/fhem/fhem-%Y-%m.log fakelog
attr autocreate filelog /mnt/logrd/fhem/%NAME-%Y.log
#...
# sowie ggf. weitere modul-logfiles...


Wer die Verzeichnisstruktur übernehmen, sollte sich bewusst sein, dass eine frische Ramdisk leer ist - ergo, das Verzeichnis /mnt/logrd/fhem existiert nicht. Hier hilft ein schnelles

Code Auswählen Erweitern

mkdir /mnt/logrd/fhem
chown fhem:fhem /mnt/logrd/fhem

in der /etc/rc.local


2) Noatime
ext4 und Freunde speichern accesstimes per default. Wer das nicht benötigt, dem lege ich dringend nahe, die option abzuschalten. Hierzu die option "noatime" in der entsprechenden Zeile in der /etc/fstab für das rootfs setzen.

Ein Beispiel:

Code Auswählen Erweitern

PARTUUID=01abcdef-02  /               ext4    defaults,noatime  0       1

[Wernieman]

Nur mal am Rande:
Der Nachteil von Logs im RAM: Bei einem reboot o.Ä. des Systemes gehen diese komplett verloren. manchmal sind fürs debuggen aber gerade diese Logfiles wichtig ...

[Sörn]

Der Nachteil von Logs im RAM: Bei einem reboot o.Ä. des Systemes gehen diese komplett verloren. manchmal sind fürs debuggen aber gerade diese Logfiles wichtig ...

Warum sollte ein Neustart mit FHEM im Zusammenhang stehen?
Mal angenommen der RAM geht zur Neige und FHEM ist Hauptverursacher - dann wird der FHEM Prozess vom OOM killer abgeschossen.

[Wernieman]

Ich hatte nicht nur von FHEM sondern auch von Systemlogs geredet ... bei FHEM-Logs gehen natürlich die Langszeitlogs verloren, wenn  Du bei einem restart diese nicht sicherst (voher)