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

[haselchen]

@opensourcenomad

Was Dein Wissen und praktische Nutzung angeht, bist du natürlich weit vorne.
Wenn ich aber deine Berechnung ansehe, was die Wahrscheinlichkeit betrifft, dann müsste hier
quasi täglich ne Karte bei den Usern abrauchen.
Ich denke schon , dass hier der Hersteller den Unterschied ausmacht.
Ich hatte mal bei einem Freund eine billige Watson SD eingebaut.
Die war nach nicht allzu langer Zeit Geschichte.
Ich selber benutze für alle Geräte, die eine SD brauchen ausschliesslich SANDISK.
Und ich denke, da pflichten mir hier viele bei, bei der Marke machste nix verkehrt.
Commit Intervall hin oder her.

[Thomas Braun]

Ich hab hier mit den Samsung Karten auch keine Probleme. Zuletzt aber mal mit einer Intenso aus dem Supermarkt. Ich glaube, die hat keine 14 Tage gehalten. War halt ein Notkauf...

[OpenSourceNomad]

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

eine billige Watson SD

Das ist nicht mal ein Hersteller von Flash, davon gibt es aktuell glaube ich noch 4 auf der ganzen Welt.

Wer etwas (halbwegs) zuverlässiges will wird um einen dieser vier nicht herumkommen.

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

Und ich denke, da pflichten mir hier viele bei, bei der Marke machste nix verkehrt.

Grundsätzlich ja, aber auch bei sandisk hat die Qualität leider abgenommen was SD Karten angeht.

Alle diese (Flash)Hersteller wissen über die write amplification bestens bescheid. Im offizellen San disk forum gibt es da nicht wenig Beiträge dazu, allerdings ausschließlich (?) im Bezug zu SSDs, die genau so wie jeder flash Speicher unter der write amplification leidet :bulb:

[OpenSourceNomad]

@thomas-braun said in RaspberryOS + ioBroker = SD Karten Killer:

Intenso

Auch kein Hersteller von Flashspeicher, ergo nicht kaufen ;)

Früher:tm: gab es immer das Gerücht das flash Bausteine welche beim Hersteller die Qualitätskontrolle nicht bestanden haben von Drittfirmen (Intenso, Watson, YouNameIt) aufgekauft und zu SD Karten und USB Sticks mit minderster Qualität verbacken wurden.

auch keine Probleme.

Die Krux ist hier halt das SD Karten, anders als zum Beispiel SSDs oder eMMCs keinerlei wear indicator (aka SMART) haben. Deswegen wird die SD Karte entweder funktionieren ("keine Probleme") oder sie wird nicht mehr funktionieren ("keine Probleme mehr machen"). Etwas dazwischen (was auf ein baldiges Ende hinweisen würde) gibt es leider so nicht.

Oft erkennt man "Tote" SD Karten übrigens am "grid lock", dann ist es nicht mehr möglich die SD Karte zu beschreiben (der flash controller versetzt die Karte quasi in einen read-only modus).

[Thomas Braun]

@opensourcenomad

Wie gesagt, war ein Notkauf. Weil die ordentlichen Dinger 'nie' kaputtgehen hatte ich keine mehr in der Schublade liegen.

[OpenSourceNomad]

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

wear indicator (aka SMART)

SSDs haben dies aber:

Quelle: https://forums.sandisk.com/t/high-very-high-waf-write-amplification-factor/72987

Anhand der SMART Data kann der WAF berechnet werden:

• 17:328 / 571 = 30,3~

Für (heutige) SSDs wäre das immer noch ein sehr hoher Faktor. Anders als SD Karten versuchen diese mit ausgefeilteren Techniken (u.a. mit extra cache, teilweise aus slc) ein unnötiges einhämmern auf die wertvollen Flashzellen zu vermeiden. Es ist heute nicht mal unüblich das SSDs (natürlich abhängig vom Anwendungsszenario) einen WAF von unter 1, über die Lebenszeit gerechnet, haben.

Es gibt übrigens eine Funktion (-d) des armbianmonitor (cli tool sollte auch auf dem rpi laufen) welches die page writes (des flashes) anzeigt bzw. überwacht. Mann kann daran sehr gut erkennen was man "verschenkt" bzw. verheizt. Wäre sehr interesant wenn die Glückspilze ( @wendy2702 , @haselchen) das mal anwerfen, bzw. jeder andere natürlich auch. Und ganz toll wäre natürlich ein vorher (default commit interval mit 5 Sekunden) und nachher (600 Sekunden commit interval) auf dem gleichen System (ohne anderen Änderungen) zu Vergleich.

[wendy2702]

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

Was ist denn dein Test/Vergleichsetup um das beurteilen zu können?

Ich vergleiche mit dem was man hier so liest bezüglich des Sterbens der SD Karten. Mein Vergleichssetup besteht aus zwei Iobroker PI3 Installationen welche bis zur Umstellung auf Proxmox zuerst als einzelne Installationen und später als Master Slave liefen, aktuell beide PI3 als Slaves. Als die noch einzeln bzw als Master/Slave liefen hatte ich so ca. 50 Instanzen laufen und z.B. die einzelnen Objekte meines WRs, die Zählerstände und Verbrauchswerte in History geloggt. Das hat häufiger dazu geführt das die Karte(n) voll waren.

Sind übrigens auch relativ alte Sandisk Karten.

Ob ich das "tool" mal teste muss ich mal schauen, nicht das nachher noch was kaputt geht ;-)

[OpenSourceNomad]

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

Ich vergleiche mit dem was man hier so liest bezüglich des Sterbens der SD Karten.

Also rein "gefühlt" oder wie soll man das verstehen? "Absolute" Zahlen für irgendwelche seriösen Vergleiche sind mir hier noch nirgends untergekommen :thinking_face:

Mein Vergleichssetup besteht aus zwei Iobroker PI3 Installationen

Mit verschiedenen commit Intervall? Das wäre tatsächlich spannend!

Ob ich das "tool" mal teste muss ich mal schauen, nicht das nachher noch was kaputt geht

Da musst du keine Angst haben, das tool arbeitet nur lesend.

Allerdings könnte dich das Ergebnis natürlich trotzdem verärgern, wenn du siehst das du nur halbvolle pages beschreibst und dein Kärtchen auch ohne Probleme die doppelte Lebenszeit haben könnte!

[OpenSourceNomad]

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

Mit verschiedenen commit Intervall? Das wäre tatsächlich spannend!

Hier hat das jemand mit einem raspberry pi zero 2 gemacht:

If you love your SD card then Raspberry Pi OS defaults are not for you: swap on SD card, default ext4 commit interval and logging to card.

root@raspberrypi:~# armbianmonitor -d mmcblk0p2
Sun Nov 14 14:43:14 GMT 2021       2/40 pages written after 5 sec
Sun Nov 14 14:43:24 GMT 2021       2/40 pages written after 5 sec
Sun Nov 14 14:43:25 GMT 2021       8/36 pages written after 1 sec
Sun Nov 14 14:43:36 GMT 2021       2/40 pages written after 7 sec
Sun Nov 14 14:43:41 GMT 2021       1/4 pages written after 1 sec
Sun Nov 14 14:43:45 GMT 2021       2/60 pages written after 4 sec
Sun Nov 14 14:43:55 GMT 2021       2/44 pages written after 5 sec
Sun Nov 14 14:44:06 GMT 2021       2/40 pages written after 6 sec

Every few seconds a few bytes are written to SD card. This write pattern results in high Write Amplification and the SD card will die way earlier than necessary.

Und hier mit Optimierung:

root@raspberrypi:/home/pi# date
Sun 14 Nov 15:09:28 GMT 2021
root@raspberrypi:/home/pi# armbianmonitor -d mmcblk0p2
Sun Nov 14 15:15:48 GMT 2021       2/196 pages written after 378 sec
Sun Nov 14 15:16:18 GMT 2021      33/152 pages written after 30 sec
Sun Nov 14 15:17:01 GMT 2021       1/60 pages written after 43 sec
Sun Nov 14 15:20:47 GMT 2021       1/12 pages written after 226 sec
Sun Nov 14 15:21:03 GMT 2021       2/16 pages written after 16 sec
Sun Nov 14 15:21:04 GMT 2021       2/8 pages written after 1 sec
Sun Nov 14 15:21:10 GMT 2021       4/36 pages written after 6 sec
Sun Nov 14 15:21:15 GMT 2021       3/20 pages written after 5 sec
^C
root@raspberrypi:/home/pi# date
Sun 14 Nov 15:21:35 GMT 2021

Before: 8 times within 60 seconds a few bytes were written to the card, now it took 12 minutes for 8 write attempts using larger data chunks. Write Amplification significantly decreased.

[wendy2702]

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

Also rein "gefühlt" oder wie soll man das verstehen?

Ja klar "gefühlt". Wie auch anders, sonst müsste ich ja ne Rechnung der SD Karte haben und genau wissen wann ich installiert habe.

Auch müsste ich genau wissen wie lange die anderen User hier Ihre Karten im Einsatz haben/hatten.

[Thomas Braun]

Fundstücke

Get a good card, a good power supply, and don’t let others’ negative experiences, real or rumored, get you down!

Quelle: https://hackaday.com/2022/03/09/raspberry-pi-and-the-story-of-sd-card-corruption/

[OpenSourceNomad]

@smarthome2020 said in [Anleitung] Selbstbau Wemos D1 mini und Helligkeitssensor BH1750:

Bei dem Sensor passiert im log über Minuten nichts , während bei einem anderen Sensor im Log neue Einträge hinzu kommen.

schalt mal die logger component auf verbose :mag:

[OpenSourceNomad]

@thomas-braun said in RaspberryOS + ioBroker = SD Karten Killer:

and don’t let others’ negative experiences, real or rumored, get you down!

Oder:

"and don't repeat the failures of others for a quick Start!" :rocket:

Die Kommentare vom Artikel empfehlen übrigens noch log2ram. Für Installationen auf SD Karten natürlich auch Pflicht!

[AlCalzone]

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

Die Kommentare vom Artikel empfehlen übrigens noch log2ram. Für Installationen auf SD Karten natürlich auch Pflicht!

Wie kann man dann post mortem anhand von Logs Absturzursachen ermitteln? Sollten die nicht wenigstens halbwegs regelmäßig doch gespeichert werden?

[OpenSourceNomad]

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

Sollten die nicht wenigstens halbwegs regelmäßig doch gespeichert werden?

Also Armbian macht das so:

/var/log is mounted as compressed device (zram, lzo), log2ram service saves logs to disk daily and on shutdown
Source: https://docs.armbian.com/#performance-tweaks

Da der Pi nur 5V braucht ist eine unterbrechungsfreie Stromversorgung natürlich ein Kinderspiel. Mehr als eine Powerbank welche gleichzeitig ge- und entladen werden kann (und natürlich genügend power liefert) braucht man nicht. Oft sind das sogar die ollen Werbegeschenke im 18650 Stil dafür geeignet :battery:

Rein rechnerisch sollte selbst eine kleine power bank mit 1000mAh die Himbeere durch jeden Stromausfall in DE bringen, statisch gesehen sind die Versorgungsunterbrechungen in den meisten Bundesländern weniger als 10 Minuten im Jahr. :bulb:

Wie kann man dann post mortem anhand von Logs Absturzursachen ermitteln?

Ich bezweifle übrigens das in einem "normalen" (nicht auf SD Karten Lebenszeit optimierten) setup wo das log jede 5 Sekunden geflusht wird irgendetwas sinnvolles im Log zu finden ist wenn die Kiste unkontrolliert abschmiert. Oft ist ja gleich noch das Filesystem korrupt.... :boom:

[apollon77]

Sehr interessantes Thema ... ich frage mich aber ehrlich warum RaspberryOS da nicht von sich aus was gegen tut weil die Raspi Systeme werden ja "für alles und nichts" genutzt und an sich immer mit SD Karte ...

[OpenSourceNomad]

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

RaspberryOS da nicht von sich aus was gegen tut

Sehr gute Frage. Aber grundsätzlich ist Raspberry OS in der Vergangenheit ja auch schon mit anderen fragwürdigen Entscheidungen negativ aufgefallen (z.B. MS Telemetrie ungefragt ausgerollt auf allen installierten Systemen). Als ob das im auf dem Himbeeren vorinstallierte ThreadX "rootkit" von MS nicht schon genug wäre :laughing:

Ich selber benutze das OS von der Raspberry Pi Trading Ltd nicht, gibt ja genügend seriöse alternativen. Wenn ich mich recht entsinne läuft Debian (wahrscheinlich ebenfalls mit default ext 4 commit Intervall von 5 Sekunden!) auf allen Himbeeren und Armbian hat für den Pi 4 eine beta stable mit allen Optimierungen die ein SBC so benötigt. Letzteres is natürlich die erste Wahl wenn man das Rad nicht neu erfinden will :rocket:

[loverz]

Ich bin unerfahrener Nutzer, hab mir aber hier alles durchgelesen.
Sehe ich das richtig, dass man nur:

1. Den Befehl:

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

ausführen muss.

2. Die SWAP-Datei egal ist, wenn man genug RAM hat und dieser sowieso die ganze Zeit mehr leer als voll ist.

3. Noch was mit Log2RAM machen sollte, oder ist das im Befehl unter 1. schon abgegolten und daher unwichtig?

[OpenSourceNomad]

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

Den Befehl:

Dieser Befehl stellt das commit Intervall des filesystem vom default (5 Sekunden) auf 600 Sekunden. Dadurch werden defacto alle "geplanten" Schreibaktionen defacto für (bis zu) 10 Minuten gesammelt (im RAM) und dann gemeinsam (flash schonend) geschrieben.

Die SWAP-Datei egal ist, wenn man genug RAM hat

Mit genügend RAM kann man SWAP dann eigentlich auch gleich deaktivieren, dann führt es sicher zu keinerlei Schreibaktionen auf der SD Karte

Noch was mit Log2RAM machen sollte, oder ist das im Befehl unter 1. schon abgegolten und daher unwichtig?

Der erste Befehl ändert nur indirekt was an den Logs. Diese werden dann nicht mehr alle 5 Sekunden in's FS gehammert sondern nur noch alle 10 Minuten.

Log2ram (je nach Einstellung) flusht das Log z.B. nur täglich und zusätzlich vor dem herunterfahren (so die armbian defaults).

[loverz]

@opensourcenomad danke für die ausführliche Erklärung.

Für die meisten macht Log2RAM dann vermutlich keinen Sinn.
Ich denke alle 10 Minuten ist ein guter Wert. Man könnte den je nach RAM Größe ja bestimmt auch auf 30 oder 60 Minuten erhöhen denke ich.

Gibt es noch ein Befehl zur SWAP-Deaktivierung?

Und nochwas:
Gibt es einen Befehl, mit dem man sehen kann, wie hoch das aktuell eingestellte commit intervall ist?