NEWS
Raspberry SD Karte defekt, seltsame Dinge
-
@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.
@thomas-braun
Bei mir kommt als Ergebnis (mit der neuen Karte):grep: ext4: Datei oder Verzeichnis nicht gefundenJürgen
-
@thomas-braun
Bei mir kommt als Ergebnis (mit der neuen Karte):grep: ext4: Datei oder Verzeichnis nicht gefundendmesg -T | grep -i ext4 -
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! :+1:
-
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.)@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!
Jürgen
-
@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 :)Meine Adapter und Widgets
TVProgram, SqueezeboxRPC, OpenLiga, RSSFeed, MyTime,, pi-hole2, vis-json-template, skiinfo, vis-mapwidgets, vis-2-widgets-rssfeed
Links im Profil -
@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.
-
@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 :)@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!
Jürgen
-
@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
-
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!!
Jürgen
-
@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. -
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:
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 :face_with_rolling_eyes:
Jürgen
-
@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 :face_with_rolling_eyes:
Das ist eine mount-Option. Also in der /etc/fstab oder in
mount | sortIch vermute aber, das sind die üblichen 5 Sekunden.
486
Online32.5k
Benutzer81.8k
Themen1.3m
Beiträge