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

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