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

Mon Aug 15 04:20:13 EDT 2005

Update of /home/cvs/mtd/Documentation/jffs3

Modified Files:
JFFS3design.tex
Log Message:

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\\
\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
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 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},