mtd/fs/jffs3 JFFS3design.tex,1.24,1.25
Artem Bityuckiy
dedekind at infradead.org
Sat Feb 26 09:54:29 EST 2005
Update of /home/cvs/mtd/fs/jffs3
In directory phoenix.infradead.org:/tmp/cvs-serv18491
Modified Files:
JFFS3design.tex
Log Message:
Muscellanious refinements.
Index: JFFS3design.tex
===================================================================
RCS file: /home/cvs/mtd/fs/jffs3/JFFS3design.tex,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- JFFS3design.tex 26 Feb 2005 12:40:41 -0000 1.24
+++ JFFS3design.tex 26 Feb 2005 14:54:26 -0000 1.25
@@ -29,7 +29,7 @@
\pagestyle{empty}
\begin{abstract}
This document discusses various JFFS3 high-level design aspects.
-Additionally, this document tries to define standard JFFS3 dictionary and terms.
+Additionally, it defines standard JFFS3 dictionary and terms.
\end{abstract}
%
@@ -52,15 +52,14 @@
JFFS3 file-system is protected by checksum. Nothing is stored on the flash media
without checksum.
-Checksums are destined to detect errors when flash becomes corrupted owing
-to wear, BB appearance or external factors (abnormal temperatures and the
-like). Thus, it is worth distinguishing between \emph{permanent} and
-\emph{occasional} error:
+Checksums are destined to detect errors caused by wearing, BB appearance
+or external factors (radiation, abnormal temperatures and the
+like). Errors fall into the following caticories.
\begin{itemize}
-\item \emph{permanent} error is an error which stays after the corresponding block has
-been erased;
-\item \emph{occasional} error is an error which becomes fixed after the corresponding
+\item \emph{Permanent} error is an error which stays after the corresponding block has
+been erased.
+\item \emph{Occasional} error is an error which becomes fixed after the corresponding
block has been erased.
\end{itemize}
@@ -70,7 +69,7 @@
\begin{itemize}
\item \emph{NOR}
flash is the most trustworthy type of flashes which doesn't admit of permanent
-errors. Any permanent error is critical and means the chip is not workable anymore.
+errors. Any permanent error is critical and means that the chip is not workable anymore.
Nevertheless, some kinds of NOR flash are not avoid of very rare bit flipping
events and the use of checksum still might make sense here.
@@ -99,16 +98,16 @@
%
\subsection{Checksum modes}
Because of a significant disparity in the reliability between different types of
-flashes JFFS3 might operate in two of the following modes.
+flashes JFFS3 might operate in either of the following modes.
\begin{enumerate}
\item \emph{Strict mode} -- checksums are always verified i.e. anything JFFS2
-has read from flash is validated by checksum. This is safest operation mode and
+reads from the flash is validated by checksum. This is safest operation mode and
should probably always be enabled by default at least with NAND/AND flashes.
\item \emph{Relaxed mode} -- data checksums are not ever being checked, i.e
JFFS3 still checks node headers and other internal data but doesn't check actual
-file's content. This is dangerous working mode is probably can only be enabled
+file's content. This is dangerous working mode and may probably only be enabled
by default when JFFS3 works on top of NOR flash.
\end{enumerate}
@@ -116,44 +115,46 @@
saves checksums when it is performing write operations.
If the underlying flash makes use of ECC (e.g., NAND), and JFFS3 has been
-reported ECC error, JFFS3 checks the corresponding data that has just been read.
+reported ECC error, JFFS3 checks the corresponding data that had been read.
The checksum mode might be set on the per file basis with
help of the corresponding extended attribute. In this case the extended
-attribute overrides the default mode.
+attribute overrides the default mode. This is very handy mechanism
+whereby users might, for example, disable the checking of multimedia
+file's content.
%
% Checksum and unclean reboots
%
\subsection{Checksum and unclean reboots}
-Unlike JFFS2, JFFS3 does not utilize checksums to detect unclean reboots, albeit
-they might be engaged. The primary aim of checksum is preventing problems
-relating to a physical media corruption. Unclean reboots are primarily
+Unlike JFFS2, JFFS3 does not utilize checksum to detect unclean reboots, albeit
+might do this. The primary aim of checksum is to prevent problems
+related to physical media corruptions. Unclean reboots are substantially
detected by means of summary nodes. This property makes it possible to distinct
-between checksum errors caused by media problems and by unclean reboots and
-not to print a warning message in the latter case and the like.
+between checksum errors caused by media problems and by unclean reboots.
%
% Checksum errors
%
\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 is as follows.
+an unclean reboot, JFFS3 behaves as follows.
\begin{enumerate}
-\item The fact of error is reported.
+\item Reports the fact of the checksum error.
-\item Take attempt to recover the erroneous node.
-Ignore the erroneous node (possibly, marking it obsolete) irrespective
+\item Takes an attempt to recover the erroneous node.
+Ignores 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 Locks the inode to whom the erroneous node belongs. Namely,
+rejects any further access to the inode. This might be implementing by
+means of setting the relating extended attribute. JFFS3
+must not reject xattr operation whereby user might 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.
+\item Returns an error if the operation was being done on behalf of an
+user process (not Garbage Collector). Otherwise, let the GC to carry on.
\end{enumerate}
@@ -163,10 +164,10 @@
\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
+unimportant although it should be kept in mind during JFFS3
implementation.
-Generally, JFFS3 might try to find older obsolete node
+Conceivably, 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
@@ -221,7 +222,7 @@
\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
+occupied by dirt. Another substantial aspect GC is responsible for is
the wear-levelling support and the production of pristine nodes.
\item \emph{Node} --
@@ -242,7 +243,7 @@
type.
\item \emph{Padding node} -- fake node representing nothing and
-mainly produced when JFFS3 synchronizes the write buffer(s) or the end
+as a rule 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.
@@ -255,7 +256,7 @@
\item \emph{Valid node} -- not obsolete node.
\item \emph{Vblock, virtual block} --
-JFFS3 may treat several blocks as one vblock of bigger size.
+JFFS3 may treat several blocks as one vblock of larger size.
Thus, the minimal erasable flash unit from the JFFS3's viewpoint
is vblock which consists of one or more flash blocks.
More information about the linux-mtd-cvs
mailing list