Flash-memory: Extend presentations and handout

Extend presentations and handouts for MTD, UBI and Flashfilesystems.
Add ECC, YAFFS2, Fastmap and other items.

Signed-off-by: Holger Dengler <dengler@linutronix.de>

1 files changed, 51 insertions, 4 deletions

diff --git a/flash-memory/ubi/handout_ubi_de.tex b/flash-memory/ubi/handout_ubi_de.tex
index 15f0f8d..e8402aa 100644
--- a/flash-memory/ubi/handout_ubi_de.tex
+++ b/flash-memory/ubi/handout_ubi_de.tex
@@ -30,12 +30,12 @@ beim Wear-Leveling, das UBI ebenfalls durchführt. Ebenso können defekte
 Eraseblöcke durch andere Blöcke ersetzt werden.
 
 Durch den von UBI verwendeten Algorithmus ist es selbst beim Neuanlegen
-eines Volumes kaum vorhersagbar, welche physikalischen Eraseblöcke auf
-dem Flash es belegt. Während eine MTD-Partition immer in denselben
+eines Volumes kaum vorhersagbar, welche physikalischen Eraseblöcke es auf
+dem Flash belegt. Während eine MTD-Partition immer in denselben
 aufeinanderfolgenden Blöcken liegt, ändert sich die Zuordnung von
 physikalischen Eraseblöcken des Flash zu logischen Eraseblöcken des
 Volumes im laufenden Betrieb dynamisch. Ein UBI-Volume mit drei
-Eraseblöcken kann also durchaus die Blöcke 814, 27 und 1013 belegen.
+Eraseblöcken kann also durchaus die physikalischen Blöcke 814, 27 und 1013 belegen.
 
 Aus diesem Ansatz ergibt sich auch der Name \emph{Unsorted Block Images}.
 
@@ -67,7 +67,7 @@ in einem Vorgang geschrieben werden muss.
 
 Dynamische Volumes sind dafür gedacht, ein Dateisystem zu enthalten.
 Man verwendet sie also beispielsweise für ein Root-Filesystem oder für
-Volumes, die Nutzerdaten enthalten. 
+Volumes, die Nutzerdaten enthalten.
 
 Dynamische Volumes verwendet man am Besten mit dem Dateisystem ubifs.
 
@@ -85,6 +85,53 @@ gegenüber jffs2 hat, wird UBIGLUEBI in der Regel nicht mehr benötigt.
 
 \includegraphics[width=8cm]{images/ubi-big-picture.png}
 
+\paragraph{Fastmap}
+
+UBI legt in jedem Eraseblock einen Information Header an, der Metadaten wie
+z.b. die Zuordnung von physikalischem Eraseblock (PEB) zu logischem Eraseblock
+(LEB) beinhaltet. Diese Informationen müssen beim Hinzufügen eines UBI
+Devices (ubiattach) eingesammelt werden. Hierzu wird das entsprechende MDT
+Volume komplett gelesen und die Metadaten zusammengetragen. Der Aufwand für
+diesen Vorgang steigt damit linear zur Größe des Flash-Speichers.
+
+Um den Aufwand für das Zusammentragen der Metadaten beim Hinzufügen eines
+UBI Devices zu reduzieren, werden bei UBI Fastmap diese Metadaten persistent
+im Flash selbst abgelegt. Während des Vorgangs müssen dann nur noch die
+Speicherbereiche gelesen werden, in der die Metadaten abgelegt wurden. Die
+Zeitersparnis für ein Attach sinkt damit beträchtlich. Vor allem bei
+steigenden Flash Größen macht sich die Ersparnis deutlich bemerkbar.
+
+Hierzu legt UBI in den ersten 64 Eraseblocks einen Superblock an, der eine
+Referenz auf den Eraseblock enthält, in welchem die eigentliche Fastmap
+hinterlegt ist. Die Fastmap beinhaltet unter anderem statistische Informationen (belegte,
+freie und defekte PEBs), sogenannten Pools (Listen von belegten und freien
+PEBs), sowie den Metadaten der Volumes. Sowohl die Fastmap selbst, als auch
+die Pools können sich ihrerseits wiederum über mehrere verkettete PEBs
+erstrecken.
+
+Diese Referenzkette verhindert ein wear-out bestimmter Flash-Bereiche. So
+muss der Superblock nur dann schreibend modifiziert werden, wenn die
+Fastmap, z.B. Aufgrund eines Bit-Flips, in einem anderen PEB verlegt wird.
+Die Fastmap wiederum muss nur dann schreibend modifiziert werden, wenn sich
+die Lokation eines oder mehrerer Pools ändert.
+
+UBI Fastmap ist vollständig rückwärts kompatibel, d.h. ein mit UBI Fastmap
+generiertes UBI Volume ist auch mit einem älteren Kernel ohne UBI Fastmap
+problemlos verwendbar. Natürlich kommt hierbei der Geschwindigkeitszuwachs
+beim Attach nicht zum tragen. Ebenso ist es möglich ein bestehendes UBI
+Volume ohne Fastmap in ein UBI Volume mit Fastmap umzuwandeln,
+vorausgesetzt, es gibt genügend freie PEBs für das Ablegen der Fastmap.
+Ebenso ist es möglich, eine beschädigte oder unvollständige Fastmap zu
+rekonstruieren. In beiden Fällen muss dazu aber der gesamte Flashbereich des
+UBI Volumes gescannt werden. Die Geschwindigkeitsvorteile von Fastmap
+greifen dann erst wieder bei einem neuerlichen Attach (z.B. nach einem
+Reboot).
+
+UBI Fastmap ist so robust wie UBI selbst. Denn selbst wenn die Fastmap nicht
+gelesen werden kann oder wenn nicht genügend Platz auf dem UBI Volume
+vorhanden ist um die Fastmap zu speichern, so bleibt das UBI Volume trotzdem
+voll funktionsfähig.
+
 \subsubsection{UBI-Tools}
 
 Da UBI von den MTD-Entwicklern implementiert wurde, sind die UBI-Tools