mtd/fs/jffs3 JFFS3design.tex,1.2,1.3
Artem Bityuckiy
dedekind at infradead.org
Sun Jan 23 10:37:18 EST 2005
Update of /home/cvs/mtd/fs/jffs3
In directory phoenix.infradead.org:/tmp/cvs-serv17207
Modified Files:
JFFS3design.tex
Log Message:
Update.
Index: JFFS3design.tex
===================================================================
RCS file: /home/cvs/mtd/fs/jffs3/JFFS3design.tex,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- JFFS3design.tex 22 Jan 2005 14:04:43 -0000 1.2
+++ JFFS3design.tex 23 Jan 2005 15:37:15 -0000 1.3
@@ -7,6 +7,8 @@
%
\documentclass[12pt,a4paper,twoside,titlepage]{article}
+\usepackage{hyperref}
+\usepackage{longtable}
\begin{document}
@@ -23,8 +25,8 @@
%
\thispagestyle{empty}
\begin{abstract}
-This document contains different JFFS3 design aspects discussions.
-This document tries to define standard JFFS3 dicitionary and terms.
+This document discusses different JFFS3 design aspects.
+Additionally, this document tries to define standard JFFS3 dicitionary and terms.
\end{abstract}
%
@@ -38,61 +40,51 @@
% ABBREVIATIONS
%
\section*{Abbreviations}
-\begin{tabular}{ll}
+\begin{longtable}{p{3cm}p{11cm}}
+\large \textbf{Abbrev.} & \large \textbf{Definition} \\[7pt]
-\large \textbf{Abbrev.}
-&
-\large \textbf{Definition}
-\\[7pt]
+\emph{CRC} & Cyclic Redurancy Check \\[4pt]
-\emph{CRC}
-&
-Cyclic Redurancy Check
-\\[4pt]
+\emph{JFFS2} & Jouranlling Flash File System version 2 \\[4pt]
-\emph{JFFS2}
-&
-Jouranlling Flash File System version 2
-\\[4pt]
+\emph{JFFS3} & Jouranlling Flash File System version 3 \\[4pt]
-\emph{JFFS3}
-&
-Jouranlling Flash File System version 3
-\\[4pt]
+\emph{MTD} & Memory Technology Device \\[4pt]
-\end{tabular}
+\end{longtable}
%
% DEFINITIONS
%
\section*{Definitions}
-\begin{tabular}{p{3cm}p{11cm}}
-\large \textbf{Term}
-&
-\large \textbf{Definition}
+\begin{longtable}{p{3cm}p{11cm}}
+
+\large \textbf{Term} & \large \textbf{Definition}
\\[7pt]
-\raggedright \emph{Block, Sector}
+\raggedright \emph{Block, Sector}
&
-The minimal flash erasable unit. \\[4pt]
+The minimal flash erasable unit.
+\\[4pt]
\raggedright \emph{Eblock}
&
JFFS3 may treat several sectors as one eblock. Thus, the minimal
erasable flash unit from the JFFS3's viewpoint is eblock which consists
-of one or more flash blocks. \\[4pt]
+of one or more flash blocks.
+\\[4pt]
-\raggedright \emph{Node}
+\raggedright \emph{Node}
&
Basic JFFS3 data structure - anything which JFFS3 stores on flash is
-stored in form of node. There are different types of nodes defined.
+stored in form of nodes. There are different types of nodes defined.
Nodes have standard layout - common header, header and
data. Common header is the same for any node type. Header and
data sections are different for different node types.
\\[4pt]
-\raggedright \emph{Node common header}
+\raggedright \emph{Node common header}
&
Any node begins with common header which contains node magic
bitmask, node lenght and node type.
@@ -122,7 +114,7 @@
Each JFFS3 directory entry is represented by the direntry node.
Direntry nodes are \texttt{struct jffs3\_raw\_dirent} objects.
-\end{tabular}
+\end{longtable}
\newpage
%
@@ -137,7 +129,7 @@
%
\pagenumbering{arabic}
\section{Checksums}
-JFFS3 protects all nodes by checksums.
+JFFS3 protects nodes by checksums.
In order to be able to work with different node sections (common header,
header, data) independently, each node section has its own checksum.
@@ -152,7 +144,7 @@
possibility.
\item NAND technology implies bits flipping, but this is very rare
phenomena either;
-\item AG-AND flash chips impliy rare bit fliping in block if another block
+\item AG-AND flash chips impliy rare bit fliping in a block if another block
from a specific block group is erased;
\item etc.
\end{itemize}
@@ -163,19 +155,97 @@
reboot may happen any time and partially written nodes may
appear on the flash). JFFS2 treats any checksum error as an error caused by
unclean reboots and have no general ability to distinguish between
-checksum errors due to physical flash corruptiona and due to unclean
+checksum errors due to physical flash corruptions and due to unclean
reboots.
-In general, in JFFS3 checksum is not intended to detect errors cased by unclean
-reboots. There is another mechanism exists for this purpose.
+In general, in JFFS3 checksums are not intended (but still may be used) to detect
+errors cased by unclean reboots. There is another mechanism exists for this purpose.
+%
+% Checksum modes
+%
\subsection{Checksum modes}
-Two JFFS3 working modes are defined:
+Two JFFS3 checksum working modes are defined and
+depending on the file type and device's goal, one of them is used.
\begin{enumerate}
-\item strict mode;
-\item relaxed mode;
+\item \emph{Strict mode} - JFFS3 writes and always checks node's
+checksums. For example, it makes sense to use this checksum mode for sensitive files
+like system libraries or if for different reasons if it is needed to
+detect errors as early as possible.
+\item \emph{Relaxed mode} - JFFS3 writes, but does not check
+checsums when nodes are being read. It makes sense to use this mode on
+very reliable flashes like NOR.
\end{enumerate}
-\end{document}
+Note, if flash is additionally protected by ECC at lower (MTD
+[\ref{ref_MTD}]) layer (i.e. NAND, AG-AND or ECC'd NOR chips),
+JFFS3 checks checksums if
+ECC failure was detected even in relaxed checksum mode.
+
+The checksum mode may be setup on per-file basis using extended file
+attributes. The default checksum mode is configured at
+compilation time.
+
+%
+% Checksum algorithm
+%
+\subsection{Checksum algorithm}
+The JFFS3 checkum algorism is the pending issue. There was long
+discussion how to calculate checksum. See MTD-mailing list archives:
+December\\
+(\href{http://lists.infradead.org/pipermail/linux-mtd/2004-December/011137.html}
+{http://lists.infradead.org/pipermail/linux-mtd/2004-December/011137.html})
+and January\\
+(\href{http://lists.infradead.org/pipermail/linux-mtd/2005-January/011390.html}
+{http://lists.infradead.org/pipermail/linux-mtd/2005-January/011390.html}).
+
+Special test was written to measure different checksum algoritm's
+performance. It is wanted to run this test on different platforms.
+Currently only x86 and ARM results are known.
+
+The test and x86/ARM results may be found at \\
+\href{http://lists.infradead.org/pipermail/linux-mtd/2005-January/011403.html}
+{http://lists.infradead.org/pipermail/linux-mtd/2005-January/011403.html}.
+
+The test is
+implemented as the kernel loadable module. If you have possibility to run it on your
+platform, please do it and provide results. MIPS, ARM and PPC platforms
+are of special interest. Any suggestions are welcomed.
+\subsubsection*{JFFS2 correspondence}
+JFFS2 uses the CRC32 algoritm with
+
+\section{Miscellanious}
+This subsection contains just the gathered list of different ideas and thoughts,
+suggested by different people but have not yet highlited/used in this
+document. Many of some of them may be quite good.
+
+\begin{enumerate}
+\item Have some global or per-inode flag telling that there was a CRC
+error detected. In this flag is set, print big warning saying that flash
+device in not reliable anymore. Should be controlled by user, though
+(may be using xattr).
+
+\item Ask zlib not to generate adler32 checksum. JFFS3 write
+checksums itself.\\
+\href{http://lists.infradead.org/pipermail/linux-mtd/2004-December/011137.html}
+{http://lists.infradead.org/pipermail/linux-mtd/2004-December/011137.html}.
+
+\item Make the compression selectable per-file (may be using xattr).
+
+\item Make one more compression mode when checksums are neither
+generated nor checked.
+\end{enumerate}
+
+%
+% REFERENCES
+%
+\section{References}
+\begin{enumerate}
+\item \raggedright \label{ref_MTD}
+Memory Technology Device (MTD) Subsystem for Linux,
+http://www.linux-mtd.infradead.org/.
+\end{enumerate}
+
+\end{document}
More information about the linux-mtd-cvs
mailing list