mtd/fs/jffs3 JFFS3design.tex,1.15,1.16

[Artem Bityuckiy]

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

Modified Files:
	JFFS3design.tex 
Log Message:
Add the memory-related section


Index: JFFS3design.tex
===================================================================
RCS file: /home/cvs/mtd/fs/jffs3/JFFS3design.tex,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- JFFS3design.tex	3 Feb 2005 15:09:40 -0000	1.15
+++ JFFS3design.tex	3 Feb 2005 15:38:08 -0000	1.16
@@ -55,6 +55,8 @@
 
 \emph{CRC} & Cyclic Redurancy Check \\[4pt]
 
+\emph{GC} & Garbage Collector \\[4pt]
+
 \emph{JFFS2} & Jouranlling Flash File System version 2 \\[4pt]
 
 \emph{JFFS3} & Jouranlling Flash File System version 3 \\[4pt]
@@ -81,7 +83,7 @@
 the VM subsystem and various disk IO related subsystems. The disk data
 is cached by peaces of RAM page size (usually 4KiB),
 so any JFFS3 read/write operation
-is done in terms of pages. See \ref{ref_GormanVM} for more Linux VM
+is done in terms of pages. See [\ref{ref_GormanVM}] for more Linux VM
 details.
 \\[4pt]
 
@@ -105,7 +107,7 @@
 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.
+may be marked bad too. See [\ref{ref_ToshibaNAND}] for more details.
 \\[4pt]
 
 \raggedright \emph{Eblock}
@@ -115,6 +117,11 @@
 of one or more flash blocks.
 \\[4pt]
 
+\raggedright \emph{Garbage Collector, GC}
+&
+TODO
+\\[4pt]
+
 \raggedright \emph{Node}
 &
 Basic JFFS3 data structure -- anything which JFFS3 stores on flash is
@@ -332,7 +339,34 @@
 %
 \section{Memory consumption}
 \subsection{JFFS2 and memory consumption}
-TODO: describe JFFS2 problems
+JFFS2 has no any structure on flash, i.e., there are no
+specific addresses which one may access to get specific JFFS2 information.
+Unlike JFFS2 most file systems have the super block data structure, which
+may be found at the specified address and the information about the whole file
+system may be read from that super block. JFFS2 has no super block. The
+only it has is the set of nodes on it. Nodes may be placed to any offset within
+the flash device, so may have any position. JFFS2 just writes nodes
+sequentially.
+
+The above design assumes the following.
+\begin{itemize}
+\item When JFFS2 is being mounted, the flash media must be scanned since
+there is no super block. This is the reason why the JFFS2 mount process is slow.
+And, roughly speaking, the mount time grows lineary with the growing file
+system size.
+
+\item JFFS2 nodes have no determined position on the flash chip. They are moved by the
+Garbage Collector from time to time, so their positions are dynamically changed.
+\end{itemize}
+
+To handle this, JFFS2 keeps track of all nodes in memory.
+This means, that mrde data is on the JFFS2 file system, more RAM JFFS2 needs to
+keep track of these nodes. The memory occupied by these objects is called "in-core"
+memory.
+
+Thus, the JFFS2 in-core memory consumption is the linear
+function of the file system size.
+
 
 %
 % MISCELLANIOUS