mtd/Documentation/jffs3 JFFS3design.tex,1.15,1.16

[Artem Bityuckiy]

Update of /home/cvs/mtd/Documentation/jffs3
In directory phoenix.infradead.org:/tmp/cvs-serv885

Modified Files:
	JFFS3design.tex 
Log Message:
Add a small chapter about the map.


Index: JFFS3design.tex
===================================================================
RCS file: /home/cvs/mtd/Documentation/jffs3/JFFS3design.tex,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- JFFS3design.tex	15 Aug 2005 07:36:09 -0000	1.15
+++ JFFS3design.tex	15 Aug 2005 08:20:09 -0000	1.16
@@ -55,9 +55,9 @@
 \large{Artem B. Bityuckiy\\
 dedekind at infradead.org}\\
 \vspace{13cm}
-\large{Version 0.22 (draft)}\\
+\large{Version 0.23 (draft)}\\
 \vspace{0.5cm}
-Aug 8, 2005
+Aug 15, 2005
 \end{center}
 \end{titlepage}
 %\maketitle
@@ -234,8 +234,8 @@
 \item \emph{the map} -- contains the information about each flash
 eraseblock (wear-levelling data, bad flag, etc) and about each
 sector (\emph{used} or \emph{dirty}); the map is mainly used by the
-\emph{garbage collector} and the \emph{space allocator}; \TODO{insert
-reference}
+\emph{garbage collector} and the \emph{space allocator} (section
+\ref{ref_SectionMap}); 
 
 \item \emph{the superblock} -- contains the reference to the \emph{root node} of
 the tree, to the map, etc. as well as the static data about the whole file system
@@ -468,7 +468,7 @@
 
 Obviously, when several changes affect the same nodes, it is possible to
 apply the changes at once with less flash I/O overhead then if they would be applied
-independently. This is why the journal exists -- it allows JFFS3 to accumulate
+independently. This is why the \emph{journal} exists -- it allows JFFS3 to accumulate
 many of changes and later commit them all at once, thus, lessening the amount
 of flash I/O.
 
@@ -490,6 +490,43 @@
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %
+% THE MAP
+%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\section{The Map} \label{ref_SectionMap}
+This section describes the JFFS3 map.
+
+The JFFS3 \emph{map} is a very important JFFS3 object which contains
+information about each JFFS3 sector/block and eraseblock. Preliminarily, the
+map is an array with 2 bits per sector:
+
+\begin{enumerate}
+\item \texttt{00} -- the sector is empty;
+\item \texttt{01} -- the sector is clean (used and not dirty);
+\item \texttt{10} -- the sector is dirty.
+\end{enumerate}
+
+After every $M$ ($M$ is the number of sectors per eraseblock) 2-bit elements
+there is a per-eraseblock data structure containing the following information:
+
+\begin{enumerate}
+\item \emph{erase count} -- the number of erase cycles of the eraseblock
+(needed fo wear-levelling);
+\item good or bad;
+\item the eraseblock type (journal eraseblock, etc);
+\end{enumerate}
+
+The map may be considered as a special file which is only used internally (by
+the garbage collector and the space allocator) but is not seen outside. One way
+to organize the map is just to reserve an inode number for it and treat this
+file as any other file in the tree. But for optimization purposes, as the map
+is being changed nearly everytime, it is better to organize the map as a
+distinct $B^+$-tree with its own root, key format, etc. The root node of the
+map (the \emph{map root}) must be refered by the superblock, just like the root
+of the tree.
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%
 % SUPERBLOCK MANAGEMENT
 %
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@@ -847,6 +884,8 @@
 map in the tree because it is changes very often. Instead, the map is stored in
 a distinct dedicated $B^+$-tree.
 
+\item \textbf{Map root} -- the root node of the map.
+
 \item \textbf{Node} -- the pile of the tree. The tree consists of nodes. The
 root of the tree is the \textbf{root node}, the leafs of the tree are
 \textbf{leaf nodes}, the nodes of level 1 are \textbf{twig nodes},