Vermeidung Systemausfall durch SD-Kartenausfall

[FhemPiUser]

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...

[rudolfkoenig]

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.

[connormcl]

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).

[MadMax-FHEM]

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)...

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...

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

[connormcl]

Ja, sorry: die SD-Karte read-only; die SSD wird normal schreibbar für den Rest berieben

[Wirelesskabel]

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.

[micky0867]

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.

[Wernieman]

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)

[MadMax-FHEM]

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

[FhemPiUser]

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:

Code Auswählen Erweitern

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. 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...

[Wernieman]

wear levelling algorithmen

SSD haben einen, aber bei SD sind diese selten. Es gibt sogar Leute, die behaupten, SD haben praktisch keinen ....

[rudolfkoenig]

Was ich vergass: und natuerlich kein Swapspace.

[andies]

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.

[FhemPiUser]

Ich habe jetzt swap ausgestellt mit

Code Auswählen Erweitern


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:

Code Auswählen Erweitern

             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.

Code Auswählen Erweitern


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?

[rudolfkoenig]

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.