Defekte SD Card (nur Zur Info)

[Wernieman]

Hey,

heute ist es passiert und ich habe die erste Defekte SD Card. Kein FHEM sondern ein Monitoring-System, also ein reines Anzeigesystem, hat den Geist aufgegeben. Der Pi wollte einfach nicht mehr booten. Dadurch hatte ich die Möglichkeit, endlich mal eine Defekte SD-Card direkt zu analysieren.

Dabei ist mir aufgefallen:
- Ein Filessystemcheck der SD erbrachte keine Fehler
- Auch eine Clonen der SD erbrachte keinen Fehler und war eigentlich von der richtigen Größe

Also auf den ersten Blick nichts auffälliges (abgesehen davon, das der PI nicht booten wollte). Wir haben hier mehr als ein solches System, also einfach mal PI/SD-Card mit denen eines anderen Systems getauscht. Da der Fehler mit der SD-Card wanderte, war es zu 100% diese.

Dann habe ich mir gedacht, clone doch einfach mal eine funktionieren Karte auf die nicht "wollende" und ab dem Zeitpunkt war die SD wirklich nur noch "Schrott". Beim Schreiben meldete dd einen Fehler mangels "Größe". OK eine 16GByte Karte mit einem 16GByte Image ... kann manchmal nicht funktionieren. Während ich schauen wollte, wie ich es passend machen könnte viel mir auf, das parted nur noch 4Gbyte meldete .... 4GByte SD anstelle 16GByte? Also mehrere SD Cardreader getestet (Inkompatibilitäten? Auch Private genommen) und überall die gleichen Probleme (Außer bei zu alten Cardreadern ... ).  Scheinbar hat es auf der SD Card den Controller zerissen ..... aber das er nach dem dd schreiben eine andere Größe meldet???

Fazit:
- Eine Defekte SD Card kann man nicht per Filesystemcheck erkennen
- Ein Dump muß, auch wenn keine Fehlermeldung kam, nicht funktionieren
- Ein Filesystemcheck des Dumps brachte auch keine Erkenntnis (s.o.)(Auch wenn ich es nicht verstehe)
- Nur das Schreiben auf der Card (Komplette Schreiben) hat hier die Probleme erkennen lassen
- Immer prüfen, welche Größe die SD-Card meldet

Wenn jemand noch weiter testen will, habe hier eine defekte 16G-SD zu verschenken (Wenn die Firma mich lässt) ...
Alternativ: Bin für Testvorschläge offen .....

Edit
Seit neuestem meldet mein Laptop mit eingebautem Card-Reader per der SD auch einen netten Fehler per dmesg:

Code Auswählen Erweitern

[ 8086.740940] mmc0: unrecognised CSD structure version 3
[ 8086.740953] mmc0: error -22 whilst initialising SD card


Edit2:
Typos beseitigt

[MadMax-FHEM]

Ja eine ähnlich "Origie" bin ich anfangs auch schon mal durch...

Allerdings ohne so intensive Analyse (war da noch nicht lange im PI-Geschäft bzw. SD-Karten etc.)...

Daher habe ich NIE (mehr) bei Problemen (bzw. auch ohne Probleme   ) eine SD kopiert/gecloned sondern bin schnell dazu übergegangen bei einem OS-Wechsel gleich eine neue SD mit frischer Installation und dann fhem-Backup einspielen (mit der "Hoffnung" auf Wahrscheinlichkeit, dass es sehr unwahrscheinlich ist, dass genau DIESE Dateien betroffen sind / sollte überhaupt was sein   )...

Und aktuell laufen alle ("wichtigen") PI auf SSD...

Danke für die Tests und Infos!

Gruß, Joachim

[Wernieman]

Naja .. es hatte meinen beruflichen Ergeiz geweckt ...

Und dann wollte ich einfach mal meine Erfahrungen teilen ;o)

P.S. Damit sieht man: Es ist nicht von FHEM abhängig.

[rcmcronny]

Hallo,

ich hab das auch ab und an mal nach 3-5 Jahren Laufzeit. Meistens sind die SD Karten dann im "nur lesen" Modus. Heisst man kann noch ein Image machen, das man dann auch lokal testen und checken kann.
Ich habe aber ja auch die Backups, so dass es nie ein Problem ansich für mich ist, es kostet halt 15 min Zeit, das Backup auf eine neue SD Karte zu schreiben und gut
Hardwaredefekt hatte ich bisher noch nie vom Pi.

Ich kann aber auch bestätigen: Wenn man auf so eine Karte versucht zu schreiben, passiert entweder nix (im System kommt halt R/O Only wegen Fehlern) und bei SD Kartenlesern dann seltsame Dinge, wenig Platz, andere Größe usw .. Ich vermute da auch, das der SD Karten Kontroller einfach weniger Flash infolge Defekts nutzen kann  oder ein Teil vom Kontroller direkt "Tod" sind, wird man so oder so nichts machen können, ergo vernichten ,Backup Karte bespielen, rein und gut

Ronny

[andies]

Da ich gerade dieselbe Odyssee vor mir habe: wie oft macht Ihr backups? Täglich? Ich habe bei den Rolladen dort readings, die eigentlich, nach jeder Bewegung ein backup nötig machen würden (somfy rolling code).

[Frank_Huber]

FHEM Backup jede Nacht,
DD Image 2 x im Monat.
(Vollautomatisch ohne manuelles zutun)

[Wernieman]

Ich muß gestehen, das mit dieser Erfahrung meine Meinung zu Pi als Produktives Großes FHEM System zu meiden gut war .. bei mir läuft es auf einer ZOTAX x86 Box (CI320) super ... und mit 7W auch nicht deutlich Stromhungriger als ein Pi (3)

Backup muß täglich und automatisch laufen .... alles andere ist "Spielkram"

[Damian]

Ich habe einfach eine Marken-128GB-SD-Karte genommen, obwohl 2 GB genutzt werden - da hat der Controller genug physikalische Speicheradressen, um Daten im Zweifelsfall auf frische Zellen zu verteilen.

Ansonsten kann raspi inzwischen offiziell mit stabiler Firmware von der ssd direkt booten.

[andies]

Ansonsten kann raspi inzwischen offiziell mit stabiler Firmware von der ssd direkt booten.

Hast Du da mal eine Anleitung?

[Damian]

Hast Du da mal eine Anleitung?

https://www.youtube.com/watch?v=SfxFS2mK6ok&t=199s

[rcmcronny]

Ich mache auch 2 x im Monat ein SD-Karten Image und täglich FHEM Daten.

[Otto123]

Hast Du da mal eine Anleitung?

Oder die offizielle Doku Seite
https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md

[Wernieman]

Ich habe einfach eine Marken-128GB-SD-Karte genommen, obwohl 2 GB genutzt werden - da hat der Controller genug physikalische Speicheradressen, um Daten im Zweifelsfall auf frische Zellen zu verteilen.

Was aber keine SD-Card macht ....

[MadMax-FHEM]

Ich mache auch 2 x im Monat ein SD-Karten Image

Hoffentlich nicht bei laufendem System...

Und: ein tar von beiden Partitionen reicht völlig und spart ne Menge Platz PLUS: man kann es auf jede Größe zurückspielen, sofern die SD/SSD/HDD/... genug Platz hat...

Und wirklich: täglich ein fhem Backup!? Wie oft "bastelst" du denn da rum!? Gut, wenn es autom. geht, dann geht nix verloren... Aber dann hoffentlich auch SSD (oder zumindest [mehr als] ausreichend groß)...
Oder auf ein externes System (NAS etc.)...

Gruß, Joachim

[Wernieman]

Ein Backup muß runter vom System. Ein Backup ins gleiche System ist kein Backup ....

Bei mir wird das FHEM Backup im Zuge der Gesamten Backupstrategie mit "abgewickelt" ... ist im Gesammtbackup sogar fast der kleinste Teil ....

[MadMax-FHEM]

Ein Backup muß runter vom System. Ein Backup ins gleiche System ist kein Backup ....

Letztendlich: NATÜRLICH

Und auch bei mir ist fhem nur ein kleiner Teil...

Und mir reicht das tar vom fhem-internen Backup locker.
Da ist bei mir alles drin was ich brauche.

Außenrum ist nur "nacktes" OS

Und mit meinen Notizen (bzgl. Schritte bzw. zusätzliche Pakete) ist alles ruck-zuck restored (auch) auf ein "nacktes" OS...
...so ist auch ein Umstieg auf die jeweils nächste OS-Version kein Thema (-> funktioniert wie jedes Restore von fhem )...

EDIT: und dauert bestimmt auch nicht (kaum) länger als ein Image zu restoren und dann ja doch noch fhem-Backup einzuspielen... Plus der ganzen Platzverschwendung eines Images von einer 16GB+ SD die am Ende nicht mal die Hälfte nutzt Ja gut: Platz kostet ja "nichts" (mehr)...

Gruß, Joachim

[Damian]

Was aber keine SD-Card macht ....

Wäre mir nicht sicher:

Haltbarkeit

...
Aufgrund der verwendeten Speichertechnik ist Flash-Speicher grundsätzlich nicht unbegrenzt oft beschreibbar. Allerdings besitzen alle Karten einen Algorithmus, durch den eine wesentlich längere Nutzungszeit erreicht werden kann. Dabei werden Schreibzugriffe auf einen logischen Block des Mediums auf wechselnde physische Speicherbereiche umgelenkt (englisch ,,wear leveling"), so dass beispielsweise das häufige Schreiben von Dateisystemtabellen nicht immer auf denselben Speicherzellen stattfindet und diese frühzeitig unbrauchbar machen kann. Allerdings sind die verwendeten Verfahren in der Regel nicht offengelegt und auch selten auf den Produkten vermerkt, so dass es kaum eine Auswahlmöglichkeit nach Langlebigkeit gibt. Die geschätzte Lebensdauer wird bei SLC-NAND-Chips mit 1.000.000, beim Einsatz von MLC-NAND-Chips mit 100.000 Schreibvorgängen angegeben. Lesezugriffe auf Flash-Speicher sind unbegrenzt möglich.

Quelle: https://de.wikipedia.org/wiki/SD-Karte

[Wernieman]

Wäre mir neu. Bei SSD wird es gemacht, bei SD-Cards ..... lasse mich aber gerne überzeugen ...

Habe nur bisher keinen Hersteller gefunden, der wear leveling wirklich Spezifiziert. Deshalb gehe ich eher davon aus, das es dort nicht gemacht wird. Bei SD-Cards macht technisch auch viel die SD-Card-Steuereinheit, also nicht die Carte selber ...

[Otto123]

Bei WD Purple Sd Cards steht "Funktion zur Überwachung der Kartenintegrität"
https://shop.westerndigital.com/products/memory-cards/wd-purple-microsd#WDD032G1P0C
Was hier mit "has WL" dokumentiert wird https://www.reddit.com/r/raspberry_pi/comments/ex7dvo/quick_reminder_that_sd_cards_with_wearleveling/

Kann also vielleicht wirklich mittlerweile sein ... Mir ist es auch neu.

Den Abschnitt in Wikipedia halte ich schlicht für - "sehr unspezifisch" ? Der Aussage dort traue ich nicht, nicht so pauschal und allgemein.

[Wernieman]

Ich würde deshalb vom Normalfall = Nein ausgehen, es sei denn es ist spezifiziert.

Danke Otto fürs finden ;o)

[Damian]

Ich würde bei allen aktuellen Marken-SDs (Samsung, Toshiba und co.) von WL ausgehen.

[Wernieman]

Da Marken und NoName meistens heute aus der gleichen Fabrik kommen und es außerdem für Controller/Flash gar nicht so viele Firmen gibt, würde ich eher vom Gegenteil ausgehen. Das ist aber auch nur meine Meinung ....

(Und von der Gewinnmaximierung würde ich als Firma es auch nicht einbauen ... egal ob Marke oder nicht)

[Damian]

Ich habe hier noch etwas gefunden: https://buyzero.de/blogs/news/raspberry-pi-sd-karten-korruption-vermeiden-geheimnisse-der-microsd-karte

Unabhängig davon würde ich immer 5 Euro mehr ausgeben und eine größere Marken-SD kaufen alleine damit das OS nicht unnötig Blöcke verschieben muss. Bei 30 Euro und mehr sollte man natürlich besser gleich zu einer SSD greifen.

[Damian]

Das schreibt heise:

Controller & Flash
SD-Karten sind ähnlich aufgebaut wie SSDs: Ein Controller nimmt die Daten an der Schnittstelle entgegen und speichert sie im Flash. Wie SSDs benötigen SD-Karten etwas freien Speicher, um im Hintergrund Aufräumarbeiten zu erledigen und die Schreibzugriffe möglichst gleichmäßig zu verteilen. Die tatsächlich nutzbare Kapazität ist stets etwas geringer als die nominelle. Der SD-Controller arbeitet mit eigener Firmware, die sich für Produktfälschungen manipulieren lässt [1].


SD- und Micro-SD-Karten
Ein DRAM-Cache zur Beschleunigung von Schreibvorgängen wird anders als bei SSDs nicht eingesetzt, auch fehlt dem SD-Controller die Unterstützung für den Trim-Befehl – mit fortschreitender Nutzung stehen dem Controller so immer weniger freie Sepicherblöcke zur Verfügung, die Karte wird langsamer. Dagegen hilft – nach dem Backup der Daten – gelegentliches Formatieren der Karte. In hartnäckigen Fällen hilft der SD Card Formatter der SD Association.

Es lohnt sich also immer etwas mehr freien Platz auf der Karte zu haben

[Wernieman]

Es war übrigens eine "gute" SanDisk ....

[Damian]

Es war übrigens eine "gute" SanDisk ....

ja, sd ist leider eben keine ssd, ein erhöhtes Risiko wird wohl immer bleiben, auch wenn die nächste Generation knapp 1 GB/s, bis 128 TB und NVMe 1.3 sowie PCIe 3.1 mitbringt.

[andies]

https://www.youtube.com/watch?v=SfxFS2mK6ok&t=199s

Danke nochmal an alle hier, insbesondere Damian und Otto, aber auch alle anderen. Es hat zwar etwas länger gedauert, bis alles installiert war - aber jetzt läuft FHEM mit einer älteren SSD und ich hoffe, die Probleme mit SD-Karten gehören der Vergangenheit an.