Mein Fhem läuft auf einem RPI 3B mit SD-Karte und ich logge ziemlich viel. Bisher ist mein System auch nach mehreren Jahren noch nicht durch eine kaputte SD-Karte ausgefallen. Aber ganz wohl fühle ich micht nicht damit, dass mein System und das Logging auf eine SD-Karte (Sandisk Ultra) stattfindet. Alle paar Jahre tausche ich zwar proaktiv die SD Karte, aber vermutlich ist es nur eine Frage der Zeit, wann ich mal einen Systemausfall aufgrund kaputter SD Karte bekomme. Ich überlege daher, was man vorsorglich dagegen tun kann (über tägliche Backups hinaus. Die werden natürlich gemacht).
Ich weiß, dass das Thema "Logging auf NAS" schon mehrfach im Forum diskutiert wurde. Ich möchte jedoch einen unabhängigen Betrieb inkl. Logging vom NAS, da der auch mal aus sein darf.
Daher stelle ich mir folgende Fragen:
- Welche Karte hält am längsten? Bisher war ich mit der Sandisk Ultra ganz zufrieden. Oder hält eine Sandisk Extreme Pro oder eine Sandisk High Endurance länger durch?
- Kann man irgendwie einen Ausfall der SD-Karte automatisiert und halbwegs verlässlich vorhersagen quasi als zusätzlicher Schutz bzw. Frühwarnsystem, z.B. durch regelmäßige Suche nach defekten Sektoren oder so etwas wie S.M.A.R.T. / smartctl bei Festplatten oder wenigstens durch Auslesen der Betriebsstunden?
- Was passiert genau mit fhem falls das Log-Verzeichnis aufgrund defekter SD-Karte kaputt bzw. nicht beschreibbar ist? Fällt fhem dann aus?
Falls die Antwort auf die letzte Frage "nein" ist, dann könnte man einen USB-Kartenleserstick mit einer zweiten SD Karte in den Raspberry stecken und das System auf SD Karte Nr 1 und das Logging auf SD Karte Nr 2 laufen lassen. Die System-SD-Karte wird geschont, da kein Logging, und bei defekter Logging-SD-Karte wird man benachrichtigt (fragt sich noch wie das erkannt werden kann) und tauscht dann die nur die Logging-Karte während des Betriebes aus.
Macht das Sinn? Hat das mal jemand getestet?
Das Thema "SD-Karten-Ausfall bei FHEM" habe ich schon vor Jahren unter "Esoterik" abgelegt.
Ja, eine SD-Karte kann kaputtgehen.
Ja, ein FHEM System kann ausfallen.
Aber wenn man sich im Vorfeld entsprechende Gedanken für ein Desaster-Szenario gemacht (und diese auch durch Ausprobieren "geübt") hat, hat man spätestens nach 30 Minuten wieder ein funktionierendes System.
Die Frage 1 "welche Karte hält am längsten" läßt sich nicht beantworten. In Serbien läuft eines meiner unbeaufsichtigen FHEM auf einem Raspberry seit 7 Jahren 24/7 auf der gleiche NoName-SD-Karte und es gab noch nie ein Problem (trotz der Tatsache, dass auch das Logging auf die gleiche Karte läuft). Vom Hersteller scheint also die Lebensdauer nicht abhängig zu sein.
zu Frage 2: nein
zu Frage 3: probier es doch einfach aus. Setze die Rechte auf das Logverzeichnis auf 000 und beobachte, was passiert. Ansonsten kann ich nur empfehlen, das Logging nach DbLog zu verlegen und diese Logdatenbank regelmäßig automatisiert zu sichern.
Meine Haussteuerung (fhem & iobroker) läuft in einer virtuellen Maschine (Debian Buster) auf einem HP Proliant Server mit 128 GB RAM und 8 GB Festplattenspeicher im RAID Verbund. Für die virtuelle Maschine sind 16 GB RAM reserviert. Ich erstelle wöchentlich ein Snapshot der vm und monatlich ein komplett Backup auf meinem NAS ebenfalls mit gespiegelten Festplatten. Sollte die vm dahinsein (ist auch schon vorgekommen) wird sie ausgetauscht gegen das letzte Backup, das ich zur Not, falls der Server hin ist, auch auf nem nuk betreiben könnte. Maximaler System Ausfall bei mir 15 Minuten durch zu viel Spielerei/Experimente, wodurch ich mein Debian geschrottet habe ;-) OK vom Stromverbrauch (durchschnittlich 260Watt} nicht vergleichbar mit einem raspi, aber der Server läuft bei mir sowieso 24/24...
Zitat von: betateilchen am 18 Oktober 2020, 16:58:34
Aber wenn man sich im Vorfeld entsprechende Gedanken für ein Desaster-Szenario gemacht (und diese auch durch Ausprobieren "geübt") hat, hat man spätestens nach 30 Minuten wieder ein funktionierendes System.
...
zu Frage 3: probier es doch einfach aus. Setze die Rechte auf das Logverzeichnis auf 000 und beobachte, was passiert. Ansonsten kann ich nur empfehlen, das Logging nach DbLog zu verlegen und diese Logdatenbank regelmäßig automatisiert zu sichern.
Zum Wiederherstellen: Ja, das geht schnell, wenn man da ist und Zeit hat: Letztes Backup-Image suf SD-Karte brennen und reinstecken (logs können danach zusammengeführt werden). Das Problem ist nur, wenn man nicht da ist oder keine Zeit hat (Arbeit, Urlaub,...). Dann kann das Stunden oder Tage dauern und wäre ein problem...
Zu 3) Habs versucht ein Logfile mit chmod 000 auf nicht schreibbar gestellt. Komischerweise konnte fhem trotzdem in das log schreiben, selbst nachdem ich es per chown noch einem anderen user gegeben habe. Gelten die Rechte nur nach Neustart/Neu öffnen des Files? Oder wie kann ich das testen?
ZitatGelten die Rechte nur nach Neustart/Neu öffnen des Files?
Ja.
Es gibt ein "set FileLog reopen" Befehl.
Zitat von: FhemPiUser am 20 Oktober 2020, 12:15:03
Zum Wiederherstellen: Ja, das geht schnell, wenn man da ist und Zeit hat: Letztes Backup-Image suf SD-Karte brennen und reinstecken (logs können danach zusammengeführt werden). Das Problem ist nur, wenn man nicht da ist oder keine Zeit hat (Arbeit, Urlaub,...). Dann kann das Stunden oder Tage dauern und wäre ein problem...
Das ist meiner Meinung nach keine gute Strategie (auch wenn sie einfach und sinnvoll wirkt).
Weil:
wenn du das Image gezogen hast wo die Fehler schon im Dateisystem sind (du es aber noch nicht weißt) -> Schrott
wenn du es während dem Betrieb ziehst -> meist/oft "unbrauchbar" (open Files/Inkonsistenzen)
wenn du auf eine neue OS-Version willst: was dann?
wenn beim Abziehen kein entsprechendes "Tool" verwendet wird: viel zu viel Platzverschwendung (und oft das Zurückspielen auf kleinere SD "unmöglich" und selbst auf gleiche Größe oft "problematisch", wenn dann doch das eine oder andere Byte fehlt ;) )
Mir reicht ein fhem-Backup und meine Notizen...
Damit komme ich von 0 auf 100 in ungefähr einer halben Stunde...
Fast egal ob auf selbe OS-Version oder andere (gut außer es hat sich OS-seitig etwas relevantes geändert aber dann würde es ja u.U. auch einen "Upgrade" betreffen)...
...und auch die SD-Größe ist "egal" (gut Platz für die Daten muss nat. schon sein ;) )...
EDIT: und ich trenne mich bei so einem Umzug (neue OS-Version z.B.) von Dingen, die ich nicht (mehr) brauche... ;)
Allerdings laufe ich wegen SD-Vorbeugung mittlerweile auf SSD.
(Jaja, ich weiß: PI und USB ist Mist/Kacke/... aber läuft bislang gut. / Obwohl ich SD-Ausfall nur einmal [evtl. 2x] hatte, auf 4 Systemen innerhalb von über 6 Jahren)
EDIT: 4 fhem Systeme (eins inzwischen schon länger auf SSD). In Summe habe ich ca. 10 PIs laufen (ja vielfach nur "Spielsysteme" aber trotzdem ohne SD-Ausfall, wobei von den "Spielsystemen" inzwischen auch 3 mit SSD laufen)...
Wenn du ganz Ausfallsicher sein willst, dann: Cluster-System mit HW-Anbindung über Netzwerk inkl. redundanten Switchen etc. und selbst dann hast du bei einigen Systemen ein Problem, z.B. ZWave (und ZigBee, evtl. auch EnOcean), weil da die angelernten Geräte nicht nur in fhem "stehen" (wie bei Homematic "Classic" / CUL_HM) sondern auch im "Funkmodul"...
Aber für "Notfallzwecke" läuft bei mir "Grundfunktionalität" komplett "autark": direkte Kopplung von Geräten (also ein Lichtschalter direkt mit dem Lichtaktor etc.). fhem ist zuständig für Komfort und das Aufzeichnen von Daten etc.
Gruß, Joachim
ja, fhem rsync backup über nas habe ich zusätzlich auch und ja, neuaufsatz ist sauberer, dauert aber länger zur Wiederherstellung. mein test mit wiederherstellen eines während des betriebs gezigenen sd image hat bei mir geklappt. vorteil der sd images im betrieb ist, dass man sie automatisiert regelmäßig (in mehreren versionen) erstellen kann. wenn dateien kaputt gehen sollten wegen image erstellung im betrieb dann sollten es hoffentlich wenn überhaupt logdateien sein und die kann man aus dem rsync backup wieder herstellen.
Aber Grundproblem bleibt, wenn man nicht da ist hat läuft das system für längere zeit nicht.
sicherste Lösung wäre sicher ein zweiter rpi, der bei ausfall übernehmen kann, aber das ist sicher aufwändig und es gibt auch da probleme wie du schreibst.
ich probiere es nochmal mit dem set filelog reopen und wenn möglich mit einer dedizierten log sd karte.
Beim Image ziehen im Betrieb geht es nicht nur um "kaputte" Dateien (wegen offen/inkonsistenz) sondern das Dateisystem kann "durcheinander" kommen.
Es kann dazu führen, dass der PI gar nicht mehr bootet...
Aber wenn es bei dir/für dich klappt: gut.
Viel Erfolg, Joachim
ginge nicht ein raid0 mit zwei sd karten?
Raid0!?
Bringt doch nix bzgl. Aufallsicherheit...
...wenn dann Raid1.
https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_0
https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_1
Weiß nicht, ob der PI das kann (wäre ja SW und wenn die "spinnt": naja)...
EDIT: und bzgl. Ausfall wenn keiner da -> möglichst autarker Betrieb... Also alle wichtigen Funktionen OHNE fhem ;)
Gruß, Joachim
ähh ja, raid1 meinte ich natürlich.
ja. mache auch möglichst viel autark und besonders die kritischen Dinge wie heizung etc
Auch wenn ich von Raspis schon lange weg bin und auf x86 setze - ggf. könnte ein BananaPi M2/3 (Ultra) eine Lösung sein. Fhem und Co auf die 8 GB eMMC des BPI brennen und die SD nur noch als Logging-Laufwerk verwenden. Damit sollte ein Ausfall der SD nur die historischen Daten betreffen. Oder halt direkt ne SSD dran betreiben, die haben SATA.
Alternativ als schmale Lösung halt nen USB-Stick einstecken, mounten und denn denn fürs Logging und Co verwenden, sind ja nur eine Hand voll Pfande anzupassen.
Btw, ein Brix mit SSD braucht im Mittel 7 Watt, ein Nuc mit i3 rund 10W. Kann viel Nerven schonen und ist bezüglich des Stromverbrauchs billig erkauft.
ja, aber statt usb stick oder banana ginge auch am rpi mit einem usb sd kartenleser. das war die ursprüngliche idee. von der leistung her reicht mein rpi3b für fhem...
oder ein günstiges 2bay raid gehäuse wie z.b. https://www.amazon.de/ICY-BOX-Externes-Festplatten-Aluminium/dp/B01BHR3VPA/ref=mp_s_a_1_5?dchild=1&keywords=icy+box+raid+1&qid=1603197007&sprefix=icybox+ra&sr=8-5 mit zwei günstigen ssds. wären knapp 100€, allerdings auch ca 10 watt mehr stromverbrauch...
Eine alternative Idee wäre die SD-Karte zu schonen durch Auslagerung von /opt/fhem/log (und evtl. auch /var/log) in eine Ramdisk und z.B. nur 1xtäglich auf SD-Karte zu schreiben. Bei mir werden ca. 40MB pro Tag geloggt in den o.g. Verzeichnissen. Das sollte locker ins RAM des RPI3 passen.
Dazu gibt es mehrere Artikel bezogen auf Ramdisk für /var/log eines RPI:
https://domoticproject.com/extending-life-raspberry-pi-sd-card/ (https://domoticproject.com/extending-life-raspberry-pi-sd-card/)
https://forum-raspberrypi.de/forum/thread/4046-var-log-in-eine-art-ramdisk-auslagern-weitere-optimierungen-bezgl-logs/ (https://forum-raspberrypi.de/forum/thread/4046-var-log-in-eine-art-ramdisk-auslagern-weitere-optimierungen-bezgl-logs/)
https://github.com/azlux/log2ram/ (https://github.com/azlux/log2ram/)
https://github.com/StuartIanNaylor/zram-config (https://github.com/StuartIanNaylor/zram-config)
Hat mal jemand damit Erfahrungen gemacht?
Das ist doch alles sinnfreier Voodoo-Zauber.... *kopfschüttel*
Dafür ist mir sogar mein Popcorn zu schade.
Wenn ich ein ausfallsicheres System haben will, denke ich doch nicht in Spielzeugkategorien wie Pi oder ähnlichem.
Zitat von: betateilchen am 20 Oktober 2020, 22:40:53
Das ist doch alles sinnfreier Voodoo-Zauber.... *kopfschüttel*
Dafür ist mir sogar mein Popcorn zu schade.
Wenn ich ein ausfallsicheres System haben will, denke ich doch nicht in Spielzeugkategorien wie Pi oder ähnlichem.
das ist ja nicht schwarz-weiß. natürlich kann man mit professionellen lösungen wie im rz ganz andere ausfallsicherheiten bekommen, aber auch zu einem ganz anderen preis.
es geht mir darum die ausfallsicherheit des fhem pis zu verbessern/optimieren, soweit das eben mit akzeptablen aufwand möglich ist...
Ich habe FHEM ein paar Jahre lang auf einem billigen USB-Stick betrieben ohne Probleme.
Bei der Installation habe ich darauf geachtet, dass Aenderungen nur alle 30 Minuten auf die "Festplatte" geschrieben wurden. Es waren Kernel- und mount Parameter, ich meine das Stichwort bei der Suche ist laptop-mode. Beim Stromausfall verliert man max. 30 Minuten, aber das war mir egal.
Man kann auch den Pi umstellen auf Betrieb via SSD.
Da das beim Pi 3 irreversibel ist und wohl beim Pi 4 immernoch das flashen des EEPROMs nötig macht, habe ich das so nicht in Betrieb.
Ich boote von SD-Karte das Betriebssystem und diese ist schnell ersetzbar durch Image. Zudem läuft die SSD read-only, was mögliche Dateisystemfehler eliminiert.
Alles weitere findet danach auf SSD via powered USB-Hub statt...diese hat ein Journalling-Filesystem und wird gegebenfalls dann halt gecheckt. (Natürlich trotzdem noch Backup vorhanden).
Zitat von: connormcl am 21 Oktober 2020, 01:38:36
Man kann auch den Pi umstellen auf Betrieb via SSD.
Jep, steht schon im Thread.
Bei mir laufen einige mit SSD.
ABER: es ist ein Unterschied, ob es einen SATA-Anschluss gibt oder ob es (wie beim) PI einen USB-SATA-Adapter braucht (was mich nicht stört aber evtl. relevant ist)...
Zitat von: connormcl am 21 Oktober 2020, 01:38:36
Da das beim Pi 3 irreversibel ist und wohl beim Pi 4 immernoch das flashen des EEPROMs nötig macht, habe ich das so nicht in Betrieb.
Irreversibel.
Naja, nur der Eintrag im EEPROM, dass der PI von USB booten KANN!
Aber nicht ausschließlich muss...
Wenn eine SD steckt, bootet auch ein PI3 von SD...
Steckt keine, dann eben von USB (sofern dort nat. ein Datenträger mit OS steckt ;) )...
PI4 bootet mitlerweile (aktuellsten Bootlader vorausgesetzt) ganz normal entweder von SD oder USB...
Was einer meiner PI4 auch schon tut... :)
Zitat von: connormcl am 21 Oktober 2020, 01:38:36
Ich boote von SD-Karte das Betriebssystem und diese ist schnell ersetzbar durch Image. Zudem läuft die SSD read-only, was mögliche Dateisystemfehler eliminiert.
Alles weitere findet danach auf SSD via powered USB-Hub statt...diese hat ein Journalling-Filesystem und wird gegebenfalls dann halt gecheckt. (Natürlich trotzdem noch Backup vorhanden).
Äh? Was nun? Read-only bei der SSD oder ganz normal per USB-Hub!?
(was bei einer vernünftigen SSD gar nicht nötig ist, also ein powered Hub)
Und wenn die SD nur zum Booten dient, dann wird davon nur die FAT32 Boot-Partition genutzt.
Klar die ist schnell wieder hergestellt, weil da ja nichts spezifisches drauf ist, außer u.U. ein paar Einträge in der config.txt oder cmdline.txt...
EDIT: journaling file system ist standard bei Linux ext3 aufwärts und praktisch schon beim ganz normalen PI-Image im Einsatz... ;)
EDIT: und klar Backup ist ein MUSS, egal welche Lösung. Selbst mit Raid...
Gruß, Joachim
Ja, sorry: die SD-Karte read-only; die SSD wird normal schreibbar für den Rest berieben
3 Raspis, zwei zerschossene Karten. Eine mit, eine ohne Backup. Natürlich die fette Installation OHNE Backup. Ja ja, sagt nichts ... .
Nun Raspi 3 B+ an SSD WD Green 120 GB (gelten als unkaputtbar und gabs nicht mehr kleiner).
SSD ist extraöko im Stromverbrauch, der Raspi hat ein 6,5A Hutschienennetzteil als Futter. Spannungsprobleme? Was ist das?
Raucht der Raspi ab, nehme ich einen neuen aus dem Schrank, raucht die Platte ab, nehm ich das Backup vom NAS.
Nächster logischer Schritt wäre FHEM auf NAS (das läuft eh durch). Was mich davon noch abhält, sind die GPIO auf dem Raspi. Aber inzwischen gibts ja IP-Schaltkarten ... .
Ich denke, ausfallsicher bekommst Du es nie und du benötigst immer Ersatzhardware vor Ort.
Wie Du dich aufstellst, ist jetzt eine Frage Deiner Leidenswilligkeit. 8)
Zitat von: betateilchen am 18 Oktober 2020, 16:58:34
zu Frage 3: probier es doch einfach aus. Setze die Rechte auf das Logverzeichnis auf 000 und beobachte, was passiert. Ansonsten kann ich nur empfehlen, das Logging nach DbLog zu verlegen und diese Logdatenbank regelmäßig automatisiert zu sichern.
Das kann man wohl kaum mit dem Ausfall eines USB-Sticks oder einem defekten Block vergleichen.
Fehlende Berechtigungen werden sofort an das aufrufende Programm gemeldet.
Defekte Hardware führt zu Retries auf Kernel Ebene oder Schlimmerem.
Viele Alternative "RasPi-Platformen" haben zwar einen SATA Anschluß, der ist aber eigentlich auch nur über einen USB-SATA implementiert. USB-Sata ist an sich nicht schlecht, das Problem ist der etwas unsichere USB-Anschluß. Wenn der etwas "dreckig" implementiert ist, siehe USB-Probleme beim Pi4, dann kann (und wird) es zu Problemen kommen. Es reicht auch, wenn eines ander Angeschlossenen Geräte auf USB-Ebene "Mist" baut .... und deshalb der USB-Anschluß ein Reset macht ....
Ich habe hier auch RasPis laufen, die seit Jahren keinen SD-Wechsel erlebt haben. Dafür ist mir Gestern die 2. Karte in meinem Leben in einem Pi geschrottet, obwohl dieser selten mal zu Testzwecken hochgefahren wurde. Nach meiner Analyse mal wieder ein "SD-Controller-Problem" (Zur ersten Karte hatte ich hier irgendwo mal einen Thread erfasst).
Um jetzt etwas Konkreter von meinem "Geschwafel" zu kommen:
- Es gibt kein Patentrezept um den Pi "Betriebssicherer" zu bekommen (Gilt auch für Alternativen)
- Backup ist Wichtig (und Test-Restore)
- Es gibt "bessere" Plattformen als den Pi (und Konsorten), dafür sind diese Teurer (Anschaffungspreis etc.)
- Gute Backupplanung (am besten Automatisch)
- USB etwas kritisch betrachten, kann Probleme machen
- Erwähnte ich Backup?
Also in Kurzfassung: Alles hat seine Vor/Nachteile (Abgesehen vom Guten Backup, das hat nur Vorteile)
Zitat von: connormcl am 21 Oktober 2020, 02:36:06
Ja, sorry: die SD-Karte read-only; die SSD wird normal schreibbar für den Rest berieben
Hatte mich schon gewundert... ;)
Aber wie geschrieben: wenn die SD nur zum Booten genutzt wird, dann wird dort eh nicht geschrieben ;)
EDIT: also je nachdem wo man die SSD dann mounted. Aber ich denke wie sonst die 2te Partition auf /
Ist also unnötiger Aufwand ;)
Aber wenn's beruhigt...
Allerdings einen PI3 oder PI4 direkt von SSD booten zu lassen tut nicht weh. ;)
Gruß, Joachim
Zitat von: rudolfkoenig am 20 Oktober 2020, 23:22:41
Ich habe FHEM ein paar Jahre lang auf einem billigen USB-Stick betrieben ohne Probleme.
Bei der Installation habe ich darauf geachtet, dass Aenderungen nur alle 30 Minuten auf die "Festplatte" geschrieben wurden. Es waren Kernel- und mount Parameter, ich meine das Stichwort bei der Suche ist laptop-mode. Beim Stromausfall verliert man max. 30 Minuten, aber das war mir egal.
Ein "selteneres" Schreiben schreiben auf die SD-Karte könnte eine potentielle Optimierung mit wenig Aufwand sein. Da ich eine USV habe, sollte ein Stromausfall innerhalb von 30min nicht auftreten und wenn 30min logdateien verlorengingen, wäre es auch nicht dramatisch, wenn dafür die SD-Karte bzw. das System seltener ausfällt.
Es gibt laut mapage ext4 die Option "commit", die man in der fstab angeben und hochsetzen könnte:
commit=nrsec
Start a journal commit every nrsec seconds. The default value is 5 seconds. Zero means default.
Wenn das alles wäre, wäre es einfach.
Hat das jemand als Option in der fstab für die SD-Karte mit einem höheren Wert als den default 5s (z.B. 30min)?
Die nächste Frage wäre dann, wie testet man dann, dass tatsächlich seltener geschrieben wird? iotop geht glaube ich nicht, da es "oberhalb des journal commits" die Schreibzugriffe misst (die ja weiterhin ständig stattfinden), oder?
Des Weiteren soll man größere SD-Karten verwenden als man eigentlich benötigt, da aufgrund der wear levelling algorithmen die Ausfallwahrscheinlichkeit sinkt https://raspberrypi.stackexchange.com/questions/169/how-can-i-extend-the-life-of-my-sd-card (https://raspberrypi.stackexchange.com/questions/169/how-can-i-extend-the-life-of-my-sd-card). Ohne es vorher gewusst zu haben benutze ich eine 32GB, von der nur ca. 10% benutzt sind. Evtl hatte ich deshalb bisher (zum Glück) noch nie einen SD-Kartenausfall...
Zitatwear levelling algorithmen
SSD haben einen, aber bei SD sind diese selten. Es gibt sogar Leute, die behaupten, SD haben praktisch keinen ....
Was ich vergass: und natuerlich kein Swapspace.
Ich habe seit drei Monaten Pi mit SSD und das läuft bisher wie eine Eins. Bis dahin hatte ich ständig Abstürze, weil ich es nicht lassen kann zu experimentieren. Es lag fast immer an mir, nie an der SD. Manchmal mit Rettungsversuchen über Stunden. Ich hatte mir einfach angewöhnt, das System nahezu regelmäßig neu aufzusetzen.
Ich habe jetzt swap ausgestellt mit
sudo swapoff -a
sudo service dphys-swapfile stop
sudo systemctl disable dphys-swapfile
sowie per fstab das root-dir mit der ext4 option "commit=900" gemountet.
Läuft alles und Speicher sollte genug da sein:
total used free shared buff/cache available
Mem: 975 180 88 6 706 724
Swap: 0 0 0
Jetzt würde ich gerne testen, ob tatsächlich weniger auf die SD-Karte zugegriffen wird. Jemand eine Idee, wie ich das testen kann?
ich habe es mit inotifwait probiert, sehe aber damit weiterhin ständige modifies auf die Logs. Eigentlich dürfte ja nur noch alle 900s auf die SD-Karte zugegriffen werden.
sudo apt-get install inotify-tools
inotifywait -mrq -e modify –-format %w%f /opt/fhem/log
Liegt es daran, dass inotify das falsche Tool dafür ist, da für inotify die commits/syncs bzw. deren Ausbleiben im ext4 nicht sichtbar sind (da das eine Ebene darunter stattfindet) oder gibt es seitens fhem einen explitizen Sync bei jedem Logschreiben, sodass das Hochsetzen der commit-Frequenz in der ext4-Option nichts bringt?
inotify ist das falsche Tool, sie beobachtet nicht die Festplatte, sondern das Filesystem ein-zwei logische Ebenen weiter oben. Ich meine, mit iostat kann man das Schreiben auf die Platte besser beobachten.
danke Rudolf, iostat habe ich gesucht!
Dieser Befehl monitored die geschriebene Bytes auf die SD-Karte:
sudo apt-get install sysstat
watch -n1 sudo iostat -d -p mmcblk0
Merkwürdig ist allerdings, dass der Wert "kB_wrtn" alle paar Sekunden ansteigt.
Wenn die Ausgabe korrekt ist, scheint ja die commit=900-Option nichts zu bringen.
Es scheint aber nicht an dem fhem log zu liegen, da der Wert zu anderen Zeitpunkten ansteigt als auf die Log-Dateien zugegriffen wird (gemäß inotifywait-Ausgabe). Ich habe auch alle anderen Verzeichnisse (bis auf /proc und die tmpfs-Verzeichnise /dev, /run, /sys) per inotifywait überwacht und keine Dateizugriffe identifizieren können, die mit dem Anstiegszeitpunkten von "kB_wrtn" (gemäß iostat-Ausgabe) korrelieren.
Jemand eine Idee, warum das "kB_wrtn" alle paar Sekunden ansteigt bzw. wie ich identifizerien kann, wer da offenbar ständig auf die SD-Karte schreibt?
Oder muss es da keine zeiliche Korrelation geben und es können auch die fhem log Dateizugriffe sein? In diesem Fall würde die commit=900-Option nichts bringen, da trotzdem aus irgendeinem Grund (welcher?) ständig syncs auf die SD-Karte stattfinden.
iostat merkt sich das schreiben, seit dem Booten, d.h. die Werte kbyte/s sind in Summe ...
Sonst gucke mal nach "/proc/diskstats".
Die Antwort auf "warum lässt sich zeitlich nichts zuordnen" könnte sein: cache ;)
Also das OS cashed erst mal und schreibt halt dann (irgendwann) mal...
Es macht ja Spaß hier zu lesen...
...allerdings bin ich nicht sicher, ob der ganze Aufwand der hier getrieben wird (mal abgesehen vom "sportlichen Ehrgeiz" ;) ) lohnt...
Entweder regelmäßig die SD tauschen oder auf SSD umsteigen oder ein anderes richtig hoch verfügbares System nehmen...
Weil egal wie: es ist alles nur Wahrscheinlichkeit. Die kann man kleiner bekommen...
ABER: dass es trotzalledem einen (Total)Ausfall geben kann (und damit auch potentiell wird ;) ) kannst du nicht verhindern...
(und wie so oft im Leben kommt es genau dann, wenn man es am wenigsten brauchen kann)
Nur meine Meinung...
Gruß, Joachim
danke, /proc/diskstats zeigt genau wie iostats, dass es trotz commit=900 alle paar Sekunden Schreibzugriffe auf die SD-Karte gibt.
Ich habe daher die commit-Option wieder rausgenommen, weil bringt nichts.
Also gibt es wohl leider keine Optimierung der Lebensdauer der SD-Karte mit wenig Aufwand und es bleibt dabei: Regelmäßige Backups und SD-Karte tauschen in proaktiv längeren Intervallen oder natürlich reaktiv wenn kaputt.
Alternative wäre wie einige geschrieben haben Umstieg auf anderen Speicher bzw. hochverfügbares System, was ich aber erstmal nicht mache, da mein System seit >5 Jahre bisher nie aufgrund kaputter SD-Karte ausgefallen ist (ich glaube ich habe einmal in der Zeit die SD-Karte proaktiv getauscht).
Danke an alle für die vielen Hinweise und interesanten Diskussionen!
Zitat/proc/diskstats zeigt genau wie iostats, dass es trotz commit=900 alle paar Sekunden Schreibzugriffe auf die SD-Karte gibt.
Das dürfte dann auch durch folgendes gelöst werden:
echo '1500' >/proc/sys/vm/dirty_writeback_centisecs
echo '3000' >/proc/sys/vm/dirty_expire_centisecs
echo '50' >/proc/sys/vm/dirty_ratio
echo '20' >/proc/sys/vm/dirty_background_ratio
Es gibt eben nicht nur die "eine" Stelle, wo Du dran schrauben kannst.