diff options
Diffstat (limited to 'flash-memory/ubi/handout_ubi_de.tex')
| -rw-r--r-- | flash-memory/ubi/handout_ubi_de.tex | 55 |
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 |