mtd/fs/jffs3 JFFS3design.tex,1.35,1.36

[Artem Bityuckiy]

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

Modified Files:
	JFFS3design.tex 
Log Message:
Add inode build chapter, fixes

Index: JFFS3design.tex
===================================================================
RCS file: /home/cvs/mtd/fs/jffs3/JFFS3design.tex,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- JFFS3design.tex	13 Apr 2005 17:41:07 -0000	1.35
+++ JFFS3design.tex	14 Apr 2005 12:43:00 -0000	1.36
@@ -222,7 +222,8 @@
 block devices like HDD;
 \item admitting of very efficient utilizing of "on-flight" compression which
 allows to fit a lot of data to Flash;
-\item relatively quick read and write operations.
+\item relatively quick read and write operations;
+\item natural unclean reboot robustness;
 \end{itemize}
 
 But unfortunately, there are several drawbacks, for example -- slow mount.
@@ -231,14 +232,52 @@
 takes much time, especially on large Flash partitions.
 
 To increase the mount speed JFFS2 performs as few work as possible during
-the mount process and deffers
+the mount process and defers
 a considerable amount of work to GC thread. GC thread continues
-working in backgroung (this process is called "checking" in JFFS2 as it
+working in background (this process is called "checking" in JFFS2 as it
 mostly check nodes' CRC checksums, albeit it also discovers obsolete
-nodes building temprary fragment trees and direntry lists). And the
-important thing is that during this checking proces no one could write to
+nodes building temporary fragment trees and direntry lists). And the
+important thing is that during this checking process GC can not proceed and in
+many cases no one could write to
 the file system, only read operations aren't forbidden. This is an
-additional cumberstone.
+additional cumber-stone.
+
+Thus, there are following mount problems in JFFS2:
+\begin{description}
+\item[Slow mount] To mount the file system JFFS2 scans the whole partition in
+order to recognize nodes, build per-block and per-inode nodes lists, etc. This
+is slow.
+\item[Unpleasant checking.] Just after mount JFFS2 checks all the
+inodes which results in flash re-reading, eats a lot of CPU cycles and may block
+writers. 
+\end{description}
+
+TODO: show some real numbers here.
+
+The first problem may be solved by a patch referred to as the "summary patch" and
+accessible at \url{http://www.inf.u-szeged.hu/jffs2/mount.php}.
+
+%
+% Inode build
+%
+\subsection{Inode build}
+One more JFFS2 problem is the slow inode build (\texttt{iget()} VFS call)
+implementation for both regular files and directories. Users typically start
+feeling uncomfortable starting from file sizes of about 32 MiB (this is highly
+dependent on how the file was written, i.e., how many nodes correspond to the
+file).
+
+Thus, there is one more problem with JFFS2:
+\begin{description}
+\item[Slow inode build.] The inode build process implies that JFFS2 walks
+through all the inode's nodes
+(which are data nodes for regular file and direntries for directory),
+reads the nodes, checks their CRC and builds fragtree/dirent list. And the inode
+build time is the linear function of the nodes number.
+\end{description}
+
+TODO: provide some real numbers here
+
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %