mtd/fs/jffs3 JFFS3design.tex,1.12,1.13

Artem Bityuckiy dedekind at
Sat Jan 29 06:27:20 EST 2005

Update of /home/cvs/mtd/fs/jffs3
In directory

Modified Files:
Log Message:

Index: JFFS3design.tex
RCS file: /home/cvs/mtd/fs/jffs3/JFFS3design.tex,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- JFFS3design.tex	27 Jan 2005 19:10:52 -0000	1.12
+++ JFFS3design.tex	29 Jan 2005 11:27:16 -0000	1.13
@@ -10,6 +10,7 @@
@@ -84,6 +85,14 @@
 The minimal flash erasable unit.
+\raggedright \emph{Bad block}
+NAND flashes may be shipped with bad blocks. These blocks are marked
+bad and must not be never used 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. See \ref{ref_ToshibaNAND} for more details.
 \raggedright \emph{Eblock}
 JFFS3 may treat several sectors as one eblock. Thus, the minimal
@@ -186,6 +195,12 @@
 errors cased by unclean reboots. There is another mechanism exists for
 this purpose (see section \ref{ref_sec_unclean_reboot}). 
+JFFS2 prints the CRC error message to the system log on every CRC error found.
+In syctems, where unclean reboots happen very often, this is very
+annoying. JFFS3 should be implemented such a way that it does not print
+the warning messages if the found checksum error is due to unclean
 % Checksum modes
@@ -229,6 +244,34 @@
 not fully written.
+% Behaviour in case of checksum errors
+\subsection{Behaviour in case of checksum errors}
+The common JFFS2 behaviour if the media corruption has been detected,
+is marking the file system
+with a kind of "corruptred" flag and rejecting to
+perform any IO operations with this inode. But there should a
+possibility to clean this flag and to force JFFS3 to ignore the
+corrupted nodes.
+If the checsum error is due to unclean reboot, the partially written
+nodes are just ignored.
+% Marking blocks bad
+\subsection{Marking blocks bad}
+In case of NAND or AG-AND flashes, flash blocks may become bad and may
+be marked bad. Bad blocks are not used anymore.
+According to \ref{ref_ToshibaNAND} the general method of bad blocks
+detection is the errors when writing or erasing blocks.
+If the write error has been detected, JFFS3 moves all data from
+this eblock to another eblock. Then the bogus block is erased. If the
+erase error has been detected, block is marked bad.
 % Checksum algorithm
 \subsection{Checksum algorithm}
@@ -280,12 +323,29 @@
 generated nor checked.\\
+\item Have special type of notes where we may store static inode node's
+(and may be other's) attributes like UID and GID. Perhaps, the xattr
+support may be used here.\\
+\item Implement xattr support. There are a lot of cases when having it
+would be very handy.\\
+\item Make compression selectable ber file.\\
 \item Have the end majic bitmask on all note types in order to be able
 to quickly detect the partially written nodes.\\
 \item Increase the maximum node size. We may keep several pages in one node.
-This leads to better compression and less memory consumption.\\
+This leads to better compression and less memory consumption. Ise
+zisofs-like technique when reading the node with several pages of data
 and following.
@@ -303,11 +363,15 @@
 \item \raggedright \label{ref_MTD}
 Memory Technology Device (MTD) Subsystem for Linux,\\
 \item \raggedright \label{ref_GormanVM}
 Mel Gorman, Linux VM Documentation,\\
+\item \raggedright \label{ref_ToshibaNAND}
+Toshiba NAND Flash Applications Design Guide,\\\\nand\_applicationguide\_e.pdf

More information about the linux-mtd-cvs mailing list