Schreibalgorithmus für Flashspeicher

[Peter(TOO)]

Hallo Searcher,

Wear Leveling ist wirklich das, was ich tun möchte. Die notwendigen Infos dazu sollen auf jeden Fall auf dem Flash selber vorhanden sein, da der Stick flexibel an verschiedene Geräten benutzt werden soll. Im Internet habe ich dazu jetzt genügend Infos gefunden, die mir aber allesamt mindestens eine Nummer zu groß für meine Anwendung sind; und sicher auch dementsprechend kompliziert zu implementieren sind.

Wenn du mit dem Fachenglisch zurecht kommst, kannst du nach alten Appnotes suchen, so 20-30 Jahre alt.
Damals gab es die heutigen Controller noch nicht und man musste das selbst per Software machen.

Zum 24C04 wurde damals eine Menge geschrieben. In den Anfängen hatten die eine Lebensdauer zwischen 1'000 und 10'000 Zyklen, heute stehen sie auch bei 1M.

MfG Peter(TOO)

[schorsch_76]

Um den "Master Record" zu schützen/schonen kannst du bsp. die ersten 16 Sektoren/Seiten reservieren. Die Seite 0, zeigt, welche der folgenden Seiten gerade genutzt wird. Nach x Zyklen wechselst du von "Filesystem Management" Seite 1 auf 2 ... 2 auf 3 ... usw. bis du wieder bei 1 bist. So verteilst du die Schreiblast des "Filesystems" auf 16 Seiten.

Die jeweilige aktive Seite, managt das "Filesystem". Belegte Sektoren, etc pp. Auch könnte hier hinterlegt werden wie oft schon auf welchen Block geschrieben wurde.

Die Seite 0 wird nur dann "belastet", wenn du die Seite bsp,. von 1 auf 2 springt.

Unter Linux wird bsp. UBIFS2 benutzt um auf "rohem" NAND Speicher zu arbeiten. Das was du hier hast
http://www.linux-mtd.infradead.org/doc/ubifs.html

Hier wird bsp. Beschrieben wie das Verteilen des schreiben prinzipiell funktioniert. Ab Seite 16/17 des PDFs wird es für dich sehr interessant sein. Ich denke aber dass due ruhig alles lesen kannst. Sind nur 50 Folien.
http://www.linux-mtd.infradead.org/doc/ubifs.pdf

[Ceos]

ich finde die Idee klasse, man teilt sozusagen die Fehlerwahrscheinlichkeit für den counter damit runter

die Anzahl Seiten für den Counter sollte dann idealerweise >= Anzahl an Runden im restlichen Flash sein ... die genutzten Flash Seiten würde ich für maximale Sicherheit eventuell noch doppelt nehmen und immer eine Kopie als Fallback mitführen. Halbiert zwar Grundsätztlich den Speicher bzw. die Lebensdauer aber führt zumindest nicht unmittelbar in einen Dead-Zustand sondern man kann vorwarnen dass mind. 1 Seite fehlerhaft ist

[schorsch_76]

Hier noch ein Paper der Universität Peking über Wear Leveling (auf englisch)
http://dbgroup.cs.tsinghua.edu.cn/li...11-lazyftl.pdf

[BMS]

Richtig, man kann auch wichtige Felder mehrfach (redundant) abspeichern.
Beim Lesen macht man dann z.B. eine Mehrheitsentscheidung, also z.B. 2 aus 3 oder 3 aus 5 gelesenen etc...
Das kann ja auf mehrere Pages verteilt werden. Oder auf mehrere ICs. Ein kleines RAID
Grüße, Bernhard

[Searcher]

Da ist ja nochmal was zusammengekommen. Über die Überwachung des Speichers und Ersatzschaltung von schlechten Zellen habe ich mir bisher noch keine rechten Gedanken gemacht.

Um den "Master Record" zu schützen/schonen kannst du bsp. die ersten 16 Sektoren/Seiten reservieren. Die Seite 0, zeigt, welche der folgenden Seiten gerade genutzt wird. Nach x Zyklen wechselst du von "Filesystem Management" Seite 1 auf 2 ... 2 auf 3 ... usw. bis du wieder bei 1 bist. So verteilst du die Schreiblast des "Filesystems" auf 16 Seiten.

Fand ich auch gut und das Weiterspinnen des Gedankens. Scheint mir etwas für größere Speicher zu sein, bei denen eine Suche im ganzen Speicher nach einem "Filesystem" zu lange dauert. Muß ich mir zusammen mit den geposteten Links noch gründlicher ansehen. http://www.linux-mtd.infradead.org/doc/ubifs.html läßt sich im Augenblick nicht öffnen. (timed out)

Danke und Gruß
Searcher

PS. Englisch ist kein Problem für mich. Außer Deutsch alle anderen Sprachen und vor allem fernöstliche schon