RaspberryOS + ioBroker = SD Karten Killer
-
@hansi1234 said in RaspberryOS + ioBroker = SD Karten Killer:
swap auf sd komplett deaktivieren
+1
SWAP auf SD dürfte hauptsächlich zum Tod einer SD-Karte beitragen.
Die SWAP-Partition liegt auf einemkleinen, festen Teil der Karte. Linux lagert bei der üblichen Swappiness im voreilenden Gehorsam Teile des RAM aus. Dadurch wird der (sehr kleine) SWAP-Bereich immer wieder beschrieben.
Was bei einem (Lese-)Fehler dann kaputt ist, ist völlig undefiniert. Das kann ein Stück Programm, Daten oder Systeminformation sein.
Daher ist das "meine" Standardeinstellung auf dem PI und mit den heutigen 4/8GB RAM für ein Stück ioB völlig ausreichend.
Seit der Umstellung habe ich keine defekte SD-Karte mehr gehabt. -
@hansi1234 said in RaspberryOS + ioBroker = SD Karten Killer:
Könntest du dazu noch ein kleines Tutorial schreiben?
Die Installationsanleitung für den raspi wurde hier hingehend bereits erweitert und es findet sich ein Befehl um das commit interval auf 10 Minuten zu setzen.
Bezüglich swap bin ich mir nicht sicher wie das aktuelle RaspberryOS das überhaupt umsetzt. Wenn es ein partition ist reicht es diese zu löschen, wenn es ein swap file ist muss vielleicht etwas an einer config geändert werden
@hans_999 said in RaspberryOS + ioBroker = SD Karten Killer:
Die SWAP-Partition liegt auf einemkleinen, festen Teil der Karte.
Nein, völlig falsch. Das genaue Gegenteil ist der Fall. Das war anno dazumal
, bei Festplatten so. Flash speicher erlauben es nicht beliebige Zellen zu beschreiben. Der flash controller verwaltet das komplett autark und versucht mittels wear leveling die "abnutzen" der Zellen möglichst auszubalancieren.Dadurch wird der (sehr kleine) SWAP-Bereich immer wieder beschrieben.
Das ist auch nicht ganz korrekt, selbst bei "hoher" swappiness versucht Linux vorrangig "statische" Inhalte im swap zu halten, also gerade solche die sich nicht dauernd ändern sondern hauptsächlich nur gelesen werden.
-
Bei mir wird Swap eh so gut wie nie angepackt. Macht also zusätzlich zu den Ausführungen von @OpenSourceNomad keinen Unterschied, ob der nun vorhanden ist oder ausgeknipst wurde.
Ist übrigens ein swapfile, keine Partition. -
@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!
-
@opensourcenomad nur das die SD Karten übermäßig schnell sterben habe ich zumindest bei mir, wie geschrieben, nicht feststellen können.
-
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
-
@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.
-
@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ückspilzeMit 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
-
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. -
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...
-
@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
-
@thomas-braun said in RaspberryOS + ioBroker = SD Karten Killer:
Intenso
Auch kein Hersteller von Flashspeicher, ergo nicht kaufen
Früher
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).
-
Wie gesagt, war ein Notkauf. Weil die ordentlichen Dinger 'nie' kaputtgehen hatte ich keine mehr in der Schublade liegen.
-
@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/72987Anhand 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. -
@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
-
@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
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 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 secEvery 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 2021Before: 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.
-
@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.
-
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/
-
@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
