mtd/fs/jffs3 JFFS3design.tex,1.23,1.24

[Artem Bityuckiy]

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

Modified Files:
	JFFS3design.tex 
Log Message:
Update document.


Index: JFFS3design.tex
===================================================================
RCS file: /home/cvs/mtd/fs/jffs3/JFFS3design.tex,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- JFFS3design.tex	25 Feb 2005 19:12:11 -0000	1.23
+++ JFFS3design.tex	26 Feb 2005 12:40:41 -0000	1.24
@@ -1,5 +1,5 @@
 %
-% JFFS3 High-level design
+% JFFS3 design issues.
 %
 % Copyright (C) 2005 Artem B. Bityuckiy, dedekind at infradead.org
 %
@@ -9,7 +9,6 @@
 \documentclass[12pt,a4paper,oneside,titlepage]{article}
 \usepackage{hyperref}
 \usepackage{html}
-\usepackage{times}
 \textwidth=18cm
 \oddsidemargin=0cm
 \topmargin=0cm
@@ -21,7 +20,6 @@
 %  TITLE PAGE
 %
 \title{JFFS3 design issues}
-% Feel free to add your name if you contribute to the document
 \author{Artem B. Bityuckiy}
 \maketitle
 
@@ -30,7 +28,7 @@
 %
 \pagestyle{empty}
 \begin{abstract}
-This document discusses different JFFS3 design aspects.
+This document discusses various JFFS3 high-level design aspects.
 Additionally, this document tries to define standard JFFS3 dictionary and terms.
 \end{abstract}
 
@@ -47,9 +45,9 @@
 Incomplete, working draft.
 
 %
-% CHECKSUMS
+% CHECKSUM
 %
-\section{Checksums}
+\section{Checksum}
 Any data (including actual file content and internal JFFS3 data) stored within
 JFFS3 file-system is protected by checksum. Nothing is stored on the flash media
 without checksum.
@@ -140,16 +138,40 @@
 %
 \subsection{Checksum errors}
 If a checksum error has been found and if it has not been caused by
-an unclean reboot the further JFFS3 behavior depends on the underlying flash
-type:
+an unclean reboot the further JFFS3 behavior is as follows.
 
-\begin{itemize}
-\item if the flash admits of bad blocks (NAND, etc), the erroneous node is just
-ignored since it is assumed the error is owing to new bad block;
+\begin{enumerate}
+\item The fact of error is reported.
 
-\item otherwise, JFFS3 refuses any further write requests and switches to the
-read-only mode; the erroneous node is ignored as well.
-\end{itemize}
+\item Take attempt to recover the erroneous node. 
+Ignore the erroneous node (possibly, marking it obsolete) irrespective
+of the recovery procedure result (success or failure).
+
+\item Lock the inode to whom the erroneous node belongs. Namely, reject
+any access to the inode returning -EIO. This might be implementing by
+means of setting the relating extended attribute. By all means JFFS3
+have to allow to clean the attribute that locks the inode.
+
+\item Return an error it the operation was being done on behalf of an
+user process (not Garbage Collector). Otherwise, let the GC carry on.
+
+\end{enumerate}
+
+%
+% Checksum error recovery
+%
+\subsubsection{Checksum error recovery}
+The recovery procedure
+has not been designed so far and probably we may postpone this work as
+unimportant although it should be kept in ming during JFFS3
+implementation.
+
+Generally, JFFS3 might try to find older obsolete node
+containing the corrupted information as well as to reconstruct the
+corrupted data using the corresponding in-memory data if it is present.
+The recovery is especially important in case of corrupted direntry node
+as if we just ignore it we might loose the whole file or directory with
+children.
 
 %
 % Miscellaneous
@@ -183,12 +205,27 @@
 
 \item \emph{Bad block} -- unreliable flash block which must not be exploited.
 NAND and AND flash chips may be shipped with bad blocks. These blocks are marked
-bad and must not be never used or erased. The technology also implies
+bad and must not be ever used (read, written or erased). The technology also implies
 that new bad blocks may appear during the flash's life-cycle. These blocks
-may be marked bad too.
+have to be marked bad too.
+
+\item \emph{Direntry node} -- node representing JFFS3 directory entry.
+Each JFFS3 directory entry is represented by one valid direntry node.
+
+\item \emph{Dirt, dirty space} -- the flash space which was once used
+but doesn't contain useful information anymore. Due to flash nature this
+space can't be used before the relating block has been erased. To put it
+differently, the dirty space is comprised of obsolete nodes and
+paddings.
+
+\item \emph{Garbage Collector} -- very important part of JFFS3
+design designated to reclaim dirt. Namely, GC moves
+valid nodes from dirty vblocks to newly erased vblocks reclaiming the space
+occupied by dirt. Another important aspect GC is responsible for is
+the wear-levelling support and the production of pristine nodes.
 
 \item \emph{Node} --
-basic JFFS3 data structure. Anything JFFS3 stores on flash is
+basic JFFS3 data structure. Anything that JFFS3 stores on flash is
 stored in form of node(s). There are different types of nodes defined.
 
 \item \emph{Node header} --
@@ -196,11 +233,27 @@
 data. Node header contains internal information while node data contains some
 user-visible data like file's content or name.
 
+\item \emph{Inode node} -- node representing JFFS3 inode.
+Any inode in JFFS3 is represented by one (for directory inodes) or more
+(for file inodes) inode nodes.
+
+\item \emph{Obsolete node} - a node which does not contain any
+actual information. The exact semantic of obsolete node depends on its
+type.
+
+\item \emph{Padding node} -- fake node representing nothing and
+mainly produced when JFFS3 synchronizes the write buffer(s) or the end
+of vblock has been reached and there is no enough space to write
+any meaningful node. Padding nodes facilitate the faster filesystem
+scanning.
+
 \item \emph{Summary node, summary} --
 describes the layout of full vblock. Summary is  situated at the end
 of each vblock and describes the vblock's layout, e.g. position, type,
 length, etc of all the vblock's nodes.
 
+\item \emph{Valid node} -- not obsolete node.
+
 \item \emph{Vblock, virtual block} --
 JFFS3 may treat several blocks as one vblock of bigger size.
 Thus, the minimal erasable flash unit from the JFFS3's viewpoint
@@ -258,7 +311,7 @@
 Josh Boyer\\
 Ferenc Havasi\\
 Joakim Tjernlund\\
-Jared Hulbert.
+Jared Hulbert
 
 \small{Note: feel free to remind us to include your name if it has been
 forgotten.}