UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[loverz]

@opensourcenomad kannst du bitte noch kurz erklären, wie man das aktuelle commit intervall anzeigen kann?

[OpenSourceNomad]

@loverz said in RaspberryOS + ioBroker = SD Karten Killer:

ext4 defaults

das aktuelle commit intervall

Es wird das "default" von ext4 hergenommen und das sind 5 Sekunden

[Thomas Braun]

@loverz sagte in RaspberryOS + ioBroker = SD Karten Killer:

Danke für den Link, der Befehl hier ist falsch. Der ist nur zum Swap leeren.

Nein, der Befehl leert das swapfile und schaltet es dann temporär aus.
Indem man den Service disabled übersteht diese Änderung dann auch einen Reboot.

[maxpd]

Ich hatte auch mal große Probleme mit der Performance und festgestellt, dass das Swap File immer 60 bis 100% ausgelastet war.
Die Samsung SD hat es überstanden.

Pi auf 8gb upgegraded und das SWAP File ist nun komplett leer.

Gleichzeitig auch auf eine SSD umgestiegen.

Kann ich das commit intervall einfach so nach einem iobroker stop unabhängig von einer installationsroutine ausführen?

sudo sed -i -e 's/defaults,noatime/defaults,noatime,commit=600/' /etc/fstab

[Thomas Braun]

@maxpd sagte in RaspberryOS + ioBroker = SD Karten Killer:

Kann ich das commit intervall einfach so nach einem iobroker stop unabhängig von einer installationsroutine ausführen?

Ja, das Dateisystem muss dann aber nochmal remounted werden -> Sauberer reboot am besten.

[maxpd]

@thomas-braun gibts einen befehl dit commit häufigkeit zu prüfen, da es kein feedback nach der eingabe gibt

[Thomas Braun]

@maxpd sagte in RaspberryOS + ioBroker = SD Karten Killer:

kein feedback nach der eingabe gibt

Linux: Kein Feedback = Das Kommando wurde ausgeführt.
Hast du die Kiste jetzt neugestartet? Erst dann werden die neuen Einstellungen für das Dateisystem übernommen.

[maxpd]

@thomas-braun Ja,

pi@iobroker:~ $ iobroker stop
pi@iobroker:~ $ sudo sed -i -e 's/defaults,noatime/defaults,noatime,commit=600/' /etc/fstab
pi@iobroker:~ $ sudo reboot now

[Thomas Braun]

@maxpd

Dann ist die Option auch jetzt gesetzt.

[loverz]

Hab mir jetzt influxDB in Kombination mit Grafana auf meinen Raspberry 4 mit iobroker geholt, da ich meine Stromwerte loggen will.

Folgende EInstellungen:

zusätzlich das oben genannte commit-intervall von 600 Sekunden.

Aktuell schreibt er eher nur alle 600s (10 Minuten), da ich "nur" 100-150 Änderungen in dieser Zeit habe und die 200 vorne noch nicht greift.

Denkt ihr mein Setting schadet der SD Karte sehr auf Dauer?
Hab eine 128GB drin.

Ich frage mich sowieso: Wieso schadet es der SD Karte mehr, wenn häufiger geschrieben wird, wenn doch die Anzahl der geschriebenen Datenblöcke am Ende gleich ist?

[apollon77]

@loverz sagte in RaspberryOS + ioBroker = SD Karten Killer:

Ich frage mich sowieso: Wieso schadet es der SD Karte mehr, wenn häufiger geschrieben wird, wenn doch die Anzahl der geschriebenen Datenblöcke am Ende gleich ist?

Sagen wir mal so - und das sind reine Annahmen meinerseits! - Du unterstellst der Datenbank das Sie so auf die Platter schreibt wie Du Ihr Daten gibst ... keine Ahnung ob man das so annehmen kann :-) Datenbanken optimieren auf die Dinge die Ihnen wichtig sind, nämlich Abfragegeschwindigkeit und generell Durchsatz und Datensicherheit ... Ich behaupte das Ihnen I/O ziemlich egal ist :-) - bestenfalls ist "I/O Optimierung" ein untergeordnetes Ziel. Ich persönlich bin seeeehr skeptisch bei "echten" Datenbanken auf SD-Karten generell - egal ob mySQL oder InfluxDB oder Postgres oder sonstwas.
Aber ich kann auch komplett falsch liegen ;-)

[loverz]

@apollon77 okay, dann muss ich wohl abwarten und fleißig backups machen.
Es wäre cool, wenn man die Datenbank auf Google Drive o.Ä. auslagern könnte. Klar Zugriffszeit ist dann schlecht, aber wäre in meinem -und vielen anderen Beispielen- eher nicht so wichtig ;)

[Dr. Bakterius]

@loverz Und warum nimmst du statt der SD nicht eine SSD? Ist schneller, stabiler und langlebiger (bei Markenware).

[apollon77]

@dr-bakterius jetzt kommt wieder Ingo mit Halbwissen Bzw seiner Meinung ;-)) ich erinnere mich das bei raspis sowas dann nur per usb geht. Gefahr ist das wenn ein raspi in unterversorgung mit Strom kommt er ggf mal eben seinen usb Chip abschaltet. Damit ist dann der Storage weg. ;-) klar kann/muss man dann sicherstellen. Aber ja mit ner ssd wäre es machbar.

[loverz]

@dr-bakterius ich will mein Raspberry schmal halten, also keine externen Geräte.
Außerdem wüsste ich nichtmal wie ich die Datenbank extern auslagern könnte.
Sonst stünde mir auch mein NAS zur Verfügung.
Wenn das NAS aber dann nichtmehr in den Standby kommt, habe ich einen erheblich höheren Stromverbrauch.

Ich denke bzw. hoffe, dass bei den kleinen Datenmengen in Kombination mit einer großen SD Karte das wear-leveling mir einige Jahre Spaß bereitet.

Daher möchte ich meine Schreiboperationen so gering wie möglich, so hoch wie nötig auslegen :-)

[OpenSourceNomad]

@loverz said in RaspberryOS + ioBroker = SD Karten Killer:

Ich denke bzw. hoffe, dass bei den kleinen Datenmengen in Kombination mit einer großen SD Karte das wear-leveling mir einige Jahre Spaß bereitet.

Also wenn deine 128GB Karte einen Markennamen trägt welcher auch ein Flashhersteller ist sollte das mit deinem commit Intervall von 10 Minuten hoffentlich viele Jahre durchhalten :muscle:

Daher möchte ich meine Schreiboperationen so gering wie möglich, so hoch wie nötig auslegen

Genau so sollte es Mensch machen ;)

[OpenSourceNomad]

@loverz said in RaspberryOS + ioBroker = SD Karten Killer:

Wieso schadet es der SD Karte mehr, wenn häufiger geschrieben wird, wenn doch die Anzahl der geschriebenen Datenblöcke am Ende gleich ist?

Ist das nicht im ersten Beitrag hier beschrieben?

SSD's "federn" das übrigens meist mit RAM oder SLC flash ab. Sprich kleine Chunks von Daten landen nicht direkt im Flashspeicher sondern speichern bzw. puffern die Daten bevor sie dann (hoffentlich) blockweise geschrieben werden.

SD Karten machen/können dies nicht (außer vielleicht die industrial/endurance Modelle welche 3mal soviel kosten wie ein SBC) weswegen diese eben exorbitant unter write amplification leiden wenn das default commit Intervall von ext4 nicht geändert wird welches das raspberryos mitbringt. Es gibt übrigens auch neuere/moderne filesysteme die von Haus aus schon für flashspeicher optimiert sind, eines nennt sich flash-friendly filesystem (F2FS) und ist schon seit vielem Jahren im Linux kernel :bulb:

[loverz]

@opensourcenomad hab eine Sandisk oder Samsung, weiß nicht mehr genau, aber sind beides Flash Produzenten.
Würde auch kein Billigschrott kaufen. Wenn der iobroker ausfällt geht im Haus fast nichts mehr 😂 da gehe ich kein Risiko ein.

Jetzt verstehe ich etwas mehr:
Wenn zB die Datenbankeinträge jeweils kleiner sind als ein Flash-Block, dann müsste die SD Karte zum schreiben des Eintrages trotzdem einen ganzen Block beschreiben, wenn auch nur mit wenig befüllt.
Das belastet die Zellen.

Macht es mit aktivem commit-interval eigentlich noch Sinn im influxdb Adapter eine Zeit oder gar eine Schwelle (Anzahl der DB Einträge einzustellen?
Ist das nicht mit dem Commit-interval sowieso Systemweit abgedeckt?

[darkiop]

@apollon77 sagte in RaspberryOS + ioBroker = SD Karten Killer:

@dr-bakterius jetzt kommt wieder Ingo mit Halbwissen Bzw seiner Meinung ;-)) ich erinnere mich das bei raspis sowas dann nur per usb geht. Gefahr ist das wenn ein raspi in unterversorgung mit Strom kommt er ggf mal eben seinen usb Chip abschaltet. Damit ist dann der Storage weg. ;-) klar kann/muss man dann sicherstellen. Aber ja mit ner ssd wäre es machbar.

no risk, no fun :) mein gfs brick #3 muss auch mit dem risiko leben :D Aber mit nem gescheiten Netzteil sollte das eher selten dazu kommen.

[OpenSourceNomad]

@loverz said in RaspberryOS + ioBroker = SD Karten Killer:

Macht es mit aktivem commit-interval eigentlich noch Sinn im influxdb Adapter eine Zeit oder gar eine Schwelle (Anzahl der DB Einträge einzustellen?

Ja weil...

Ist das nicht mit dem Commit-interval sowieso Systemweit abgedeckt?

Ja, aber das commit interval gibt an nach welche Zeit das filesystem spätestens auf den Datenträger schreibt :bulb: Sprich hier wird nicht das minimale Intervall festgelegt, sondern das maximale (spätestens nach z.B. 10 Minuten wird alles was bisher "gesammelt" wurde auf den Datenträger geschrieben)

Per se ist das auch gut so weil es oft sinnvoll ist Daten früher auf den Speicher zu schreiben, z.B. wenn man einen (externen) Datenträger unmounted.