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

[OpenSourceNomad]

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

Kann ich eigentlich nicht bestätigen.

Was genau? Die Existenz von write amplification?

Wer Freundchen google bemühen würde bekommt schnell auch white paper von flash Herstellern zu Gesicht, u.a. von western digital und im Kapitel Write amplification findet sich folgendes:

Optimize your write patterns
Generally speaking NAND friendly writes are sequential and in big chunks, as a
practice it is recommended to operate in:

a. Write command address alignment to a minimum of 4KB, preferred 128KB.
b. Write command length at a minimum of 4KB (for random), preferred 512KB.

also ziemlich genau das Gegenteil was ein iobroker mit db veranstaltet!

[wendy2702]

@opensourcenomad nur das die SD Karten übermäßig schnell sterben habe ich zumindest bei mir, wie geschrieben, nicht feststellen können.

[haselchen]

@wendy2702

Hab auch seit über 3 Jahren 2 Sandisk in Benutzung -> Tag und Nacht. Keine Ausfälle oder Probleme.

Dann sind wir beiden wohl Glückspilze ;)

[OpenSourceNomad]

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

das die SD Karten übermäßig schnell sterben habe ich zumindest bei mir, wie geschrieben, nicht feststellen können.

Was ist denn dein Test/Vergleichsetup um das beurteilen zu können? SD Karten haben leider anderst als SSD keine SMART Daten um den WAF nachträglich berechnen zu können.

[OpenSourceNomad]

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

Hab auch seit über 3 Jahren 2 Sandisk in Benutzung -> Tag und Nacht. Keine Ausfälle oder Probleme.
Dann sind wir beiden wohl Glückspilze

Mit verlaub hat die "Qualität" der SD Karten ihren Zentit bereits überschritten.

Habe leider die Quelle nicht zur Hand, aber die Quintessenz war in etwa das alte "Class A1" Karten von San disk und Samsung teilweise um Welten besser performen als aktuelle Karten aus der höchsten Preisklasse.

Es könnte sich bei euch also durchaus um Glückspilze handeln.

Wie auch immer die Abnutzung trotzdem um Welten höher als es sein müsste. Mit der kleinen Modifikation am commit Intervall könnten eure SD Karten dann vielleicht sogar euch überleben :bulb:

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