Read Disturb (Flash zerstört sich durch Lesen ???)

Hallo zusammen,
ich bin grad auf einen Hinweis bei Flashbausteinen gestoßen, der einem große Sorge bereiten kann.

Das Flashbausteine eine begrenze Anzahl Programmierzyklen haben ist soweit bekannt,
das es aber auch durch "Lesen" eine Zerstörung gibt ist mir völlig neu.

Schaut mal bitte diesen Artikel an:
https://buyzero.de/blogs/news/raspberry-pi-sd-karten-korruption-vermeiden-geheimnisse-der-microsd-karte

Auszug aus dem Artikel:

Zitat:

---

Read Disturb
Ein bisher noch nicht von mir erwähntes, aber besonders perfides, Phänomen ist Read Disturb. Selbst bei ausschließlichem Lesen von der Karte kann es - gerade durch das Lesen - dazu führen, dass benachbarte Speicherzellen im selben Block ihre Programmierung ändern. Die Wahrscheinlichkeit dass das passiert steigt stark nach einigen 100.000 Lesevorgängen.

---

Das scheint sich aber speziell auf MLC NAND Flashs zu beziehen.
Nun frage ich mich grad, wie das mit dem Programmspeicher (Flash) in meiner CPU aussieht.
oder meinen externen Flashbausteinen ?

Bei den externen I2C und SPI Flashbausteinen scheint es sich ja meist um "NOR" Flash zu handeln

grad noch gefunden:
Aufgrund der verwendeten Zugriffsart können NAND-Speicher nicht direkt als Programmspeicher für Mikrocontroller eingesetzt werden (diese benötigen einen linear adressierbaren Speicher mit wahlfreiem Zugriff)

Dann ist das wohl eher nur ein Problem bei den SD-Karten

Siro

Kannte ich zwar auch noch nicht, aber ist scheinbar nicht so wichtig. Weil sich der Speicher-Controler darum kümmern soll, dass nach einer bestimmten Anzahl von Zugriffen ein Block kopiert und initialisiert wird, so dass er wieder zur Verfügung steht. Die Daten sind dann sozusagen aufgefrischt und das Spiel beginnt von vorn.

War ja anfangs bei den Samsung EVO SSDs das gleiche phänomen soweit ich mich entsinne.

Wie Moppi schon schrieb sollte sich der Controller darum kümmern. Aber üblicherweise kümmert sich bei einer SD Karte niemand darum, denn SD Karten sind ja eigentlich nicht als "Festplatte" konzipiert.

Eigentlich müsste man den Kerneltreiber für die SD Anbindung in Raspis patchen und ebenfalls eine Logik einbauen die Daten regelmäßig umkopiert. Würde zwar die Schreibzyklen auf der SD KArte drücken, aber zumindest spezifischen Datenverlust vorbeugen. Aber ich glaube wer darüber nachdenkt einen Raspi wirklich permanent in eienr Anwendung einzusetzen, sollte über eine alternative Anebind externer DAtenträger nachdenken ... und wenn ich nur die Bootlsektion auf der SD platziere vielleicht nach dem Booten gelegentlich einen chronjob 1mal im Monat ausführen der die SD KArte auffrischt indem er die Date kopiert, den Bereich "formatiert" und neu hinschreibt ... oder gleich an einen anderen Platz.