Raspberry SD Karte defekt, seltsame Dinge
-
Hallo zusammen,
ich hatte heute einen sehr seltsamen Effekt:
Gestern einiges im IObroker umgestellt, einige JS-Scripte abgeändert, mehrere Adapter aktualisiert, alles bestens.
Heute morgen dann weiter gemacht und aus irgendeinem Grund (weiß den gar nicht mehr) den IObroker gestoppt und den Raspi per shutdown herunter gefahren.
Nach dem Neustart ging es dann los:
Verbindung zum IObroker: SSL Zertifikate abgelaufen....hähhh.... hab ich doch erneuert.... also Zertifikate wieder aktuell drauf, alles wunderbar.
Später stellte ich fest, dass Änderungen, die ich in VIS gestern gemacht hatte, verschwunden sind. Auch einige JavaScripte schmissen auf einmal Fehler...Datenpunkte waren nicht mehr vorhanden und was weiß ich.......hähhh....
Also Raspi neu gestartet, Login gemacht: SSL Zertifikate abgelaufen vor 61 Tagen, also nochmal die neuen Zertifikate installiert, nochmal drauf geschaut, ja Zertifikate sind aktuell im Speicher, wunderbar....
Jetzt wurde ich allerdings misstrauisch, nach Neustart wieder alte Zertifikate..... hmmmm
Nun mal versucht einen Restore über den backitup Adapter per Weboberfläche (Backup war glücklicher weise von heute Nacht), leider ohne Erfolg. Dann habe ich das letzte Backup per WinSCP direkt vom NAS in das Backupverzeichnis von IObroker kopiert, ging ohne Fehler. Dann Raspi neu gestartet und das Backup war wieder weg, obwohl es vorher definitiv da war.
....hähhh...
Fazit: SD Karte defekt, seit ueber 61 Tagen wurden alle Dateien irgendwie geCachet aber nie wirklich auf die SD-Karte geschrieben, wie geht das denn???? Glücklicherweise waren die Backups trotzdem aktuell, da ich sie nicht local auf dem Raspi speichere sondern auf dem NAS. Aber kann mir einer erklären wie so etwas unbemerkt passieren kann?
Restore: Nach Installation einer neuen SD Karte, konnte ich nach der Grundinstallation von IObroker alles aus dem Backup wieder herstellen, einzig der VIS Adapter wollte nicht, den musste ich per SSH in einer alten Version installieren und danach aktualisieren....
Das ganze zog sich jetzt den ganzen Nachmittag und nun bin ich froh dass alles wieder läuft...
Aber eine Frage hätte ich noch: Wie verdammt nochmal kann man feststellen, ob eine SD Karte ihren Schreibschutz aktiviert hat?
Jürgen
-
@coffee-junk sagte in Raspberry SD Karte defekt, seltsame Dinge:
Wie verdammt nochmal kann man feststellen, ob eine SD Karte ihren Schreibschutz aktiviert hat?
Miit einem Blick ins z. B.
dmesg -T | grep -i ext4Gesund schaut das so aus:
[Sun Nov 13 01:27:28 2022] Kernel command line: coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 smsc95xx.macaddr=E4:5F:01:0B:F7:93 vc_mem.mem_base=0x3eb00000 vc_mem.mem_size=0x3ff00000 console=tty1 root=PARTUUID=34b785c5-02 rootfstype=ext4 fsck.repair=yes rootwait [Sun Nov 13 01:27:30 2022] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none. [Sun Nov 13 01:27:30 2022] VFS: Mounted root (ext4 filesystem) readonly on device 8:2. [Sun Nov 13 01:27:31 2022] EXT4-fs (sda2): re-mounted. Opts: (null). Quota mode: none.Bei Problemen fehlt die vierte Zeile und generell schaut das anders aus.
-
generell ist es wohl nicht so einfach den health status einer sd-karte herauszufinden.
was du probieren kann ist
https://discourse.nodered.org/t/show-wear-level-of-sdcard-ssd-rpi/54370/6wear_level, realocated_sector_ct und error_read_count sind die parameter nach denen man das beurteilen kann.
eine sd-karte verteilt ja bei jedem schreibvorgang die daten und achtet darauf, das jede zelle von der anzahl gleichmäig oft beschrieben wird. bei sd karten kann eine zelle nur eine bestimmte anzahl beschrieben werden. wenn eine zelle kaputt ist, dann wird diese ausgeschlossen. dh die echte verfügbare speichermenge sinkt. das melden die karten aber nicht an das betriebssystem. auch wieviel spare_block der hersteller mitgibt ist auch nicht immer so bekannt (bei günstigeren sicherlich weniger als bei teueren, evtl sind auch bei der produktion zellen nicht nutzbar und als defekt markiert.) -
@thomas-braun
Bei mir kommt als Ergebnis (mit der neuen Karte):grep: ext4: Datei oder Verzeichnis nicht gefunden -
dmesg -T | grep -i ext4 -
@thomas-braun sagte in Raspberry SD Karte defekt, seltsame Dinge:
dmesg -T | grep -i ext4
Danke! Die Tücke lag im Detail, jetzt sieht es anders aus!
-
@oliverio sagte in Raspberry SD Karte defekt, seltsame Dinge:
generell ist es wohl nicht so einfach den health status einer sd-karte herauszufinden.
Was mich halt ungemein irritiert hat war die Tatsache, dass ich ohne Probleme Dateien auf den Raspi schieben konnte, die dort auch definitiv da waren, aber nicht wirklich auf die SD Karte geschrieben wurden.
Es muss also so eine Art Cache geben, das war mir nicht bewusst, dort bleiben die Daten wohl temporär liegen und sind dann nach einem Reboot weg. Das finde ich seltsam, da hätte ich irgendeine Fehlermeldung erwartet.
Da muss ich mich wohl noch etwas einlesen! Danke!
-
@coffee-junk
bin da jetzt auch kein spezialist, aber ich meine zu wissen, das daten auf eine sd karte immer blockweise geschrieben wird.
d.h. der treiber sammelt die daten und wenn dann die daten wieder abgerufen werden, dann stellt der treiber diese zur verfügung.
daten werden dann auf den datenträger ggfs. mit verzögerung geschrieben.
da sd karten manchmal auch nicht so schnell ist, puffert das betriebssystem die daten dann halt auch eine weile, weil es uU mehrfach versucht die daten der sd karte zu übermitteln.
der zustand kann meiner Meinung nach aber nur ein paar Sekunden anhalten, auf gar keinen Fall mehrere Minuten.
Diese gepufferten Daten sind es dann auch, die uU eine SD-Karte zerstören, wenn man einfach den Rechner ausschaltet und nicht ordentlich herunterfährt. bei sd karten ist es wegen der einfachheit halt höheres risiko wie bei ssd laufwerken, die sicherlich noch kondensatoren hat, die lang genung noch strom bereitstellen das auch der letzte schreibvorgang erledigt werden konnte.hier ist bspw der source code des sd treibers von linux
https://github.com/torvalds/linux/blob/master/drivers/mmc/core/sd.c
viel spass
-
Und ext4 macht sowas ähnliches auf Dateisystem-Ebene auch nochmal. Je nach mount-Option.
-
@oliverio sagte in Raspberry SD Karte defekt, seltsame Dinge:
der zustand kann meiner Meinung nach aber nur ein paar Sekunden anhalten, auf gar keinen Fall mehrere Minuten.
Das ist es ja auch was mich etwas stutzig macht, da meine Zertifikate vor 61 Tagen abgelaufen waren, ich also vor >61 Tagen die Zertifikate definitiv erneuert habe, muss dieser Zustand also irgendwann vor mehr als 61 Tagen eingetreten sein, als die alten Zertifikate noch gültig waren. Vor mehr als 61 Tagen habe ich neue Zertifikate installiert, die nie wirklich auf der Karte gelandet sind. Und seit diesem Zeitpunkt wurde auch nichts mehr wirklich auf die Karte geschrieben sondern irgendwo zwischengespeichert....
Dies hat sich dank USV erst heute bei dem reboot bemerkbar gemacht.
Da muss man erst mal drauf kommen!
-
You can set the commit interval to a custom value which, I believe, can be as high as a 32-bit unsigned integer number of seconds; so about 4 billion seconds, or 136 years.
Gelesen hier:
https://superuser.com/questions/479379/how-long-can-file-system-writes-be-cached-with-ext4
-
@thomas-braun sagte in Raspberry SD Karte defekt, seltsame Dinge:
Gelesen hier:
https://superuser.com/questions/479379/how-long-can-file-system-writes-be-cached-with-ext4Autsch, da fällt mir auch noch ein dass ich vielleicht heute kein
shutdownsondernrebootbenutzt habe..... im Eifer des Gefechts....Danke für die Infos!!
-
Aber auch ein
rebootschreibt wenn möglich die Daten auf den Datenträger. -
@thomas-braun sagte in Raspberry SD Karte defekt, seltsame Dinge:
https://superuser.com/questions/479379/how-long-can-file-system-writes-be-cached-with-ext4
Kann man den momentan eingestellten commit Wert irgendwie auslesen? So aus reiner Neugier fürs nächste mal
-
Das ist eine mount-Option. Also in der /etc/fstab oder in
mount | sortIch vermute aber, das sind die üblichen 5 Sekunden.
