mtd/fs/jffs3 JFFS3design.tex,1.36,1.37
Artem Bityuckiy
dedekind at infradead.org
Thu Apr 14 13:25:27 EDT 2005
Update of /home/cvs/mtd/fs/jffs3
In directory phoenix.infradead.org:/tmp/cvs-serv5224
Modified Files:
JFFS3design.tex
Log Message:
Conclusion chapter. Fixes.
Index: JFFS3design.tex
===================================================================
RCS file: /home/cvs/mtd/fs/jffs3/JFFS3design.tex,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -r1.36 -r1.37
--- JFFS3design.tex 14 Apr 2005 12:43:00 -0000 1.36
+++ JFFS3design.tex 14 Apr 2005 17:25:23 -0000 1.37
@@ -60,8 +60,8 @@
% Memory consumption
%
\subsection{Memory consumption}
-Let's make experiments using an x86 PC host with 64MiB simulated
-NAND flash (nandsim module). In all experiments below the whole
+Let's make experiments using an x86 PC host with 64~MiB simulated
+NAND flash (\emph{nandsim} simulator module). In all the experiments below the whole
flash comprises single partition where JFFS2 filesystem is put.
\begin{description}
@@ -72,8 +72,9 @@
We observed the following.
The total files number was 4372 -- 719 directories and 2995 regular
-files (all files' nodes were made pristine). The summary size of all files was 116 MiB.
-The summary size of all files was 116 MiB (compression was enabled).
+files (all the files' nodes were made pristine, i.e.,
+\texttt{PAGE\_SIZE} bytes in length).
+The summary size of the all files was 116~MiB (compression was enabled).
The memory consumed by JFFS2 was distributed over its internal objects
as follows.
@@ -89,15 +90,15 @@
\end{tabular}
\end{center}
-Note, that all inodes were in the inode cache in our experiments,
+Note, that all the inodes were in the Linux Inode Cache in our experiment,
which isn't that typical
-for the real-life system though. If no inodes were in the inode cache,
-only 658/1778/12706 KiB would be consumed by the \texttt{jffs2\_node\_ref}
+for the real-life system though. If no inodes were in the Inode Cache,
+only 658~KiB would be consumed by the \texttt{jffs2\_node\_ref}
objects. However, opening any
file or looking up in any directory would require additional RAM.
\item[Experiment 2]
-The following command on the same empty 64 MiB JFFS2 file
+The following command on the same empty 64~MiB JFFS2 file
system
\begin{quote}
\texttt{dd if=/dev/urandom of=/mnt/jffs\_mnt/file bs=512}
@@ -115,7 +116,7 @@
\end{center}
\item[Experiment 3]
-The following command on the same empty 64 MiB JFFS2 file
+The following command on the same empty 64~MiB JFFS2 file
system
\begin{quote}
\texttt{dd if=/dev/urandom of=/mnt/jffs\_mnt/file bs=10}
@@ -133,12 +134,12 @@
\end{center}
It is worth noting here, that in JFFS2 memory which is consumed even
-when no files are opened is called \emph{in-core memory}.
-In-core memory mostly consists of \texttt{jffs2\_node\_ref} objects.
+when no files are opened is called \emph{\mbox{in-core} memory}.
+\mbox{In-core} memory mostly consists of \texttt{jffs2\_node\_ref} objects.
\end{description}
Assuming the amount of consumed memory grows linearly with the flash size
-(which I believe is true) we'd have the following numbers for 1GB flash
+(which I believe is true) we'd have the following numbers for an 1GB flash
in similar experiments.
\begin{description}
@@ -184,24 +185,24 @@
\item[In-core RAM.]
Due to the design JFFS2 needs to refer each node associating a
small RAM object with it resulting in substantial RAM consumption. The
-amount of in-core RAM depends linearly on the amount of information on
+amount of \mbox{in-core} RAM depends linearly on the amount of information on
the flash. More data are put to the FS, more RAM JFFS2 takes.
-\item[Inode build RAM.] And again due to JFFS2 design built inodes (those who
-are in the inode cache, which happens when, say, a file is opened or
-a directory is browsed) consume a lot of RAM (). For files JFFS2 needs to
+\item[Inode build RAM.] And again, due to JFFS2 design built inodes (those who
+are in the Inode Cache, which happens when, say, when a file is opened or
+a directory is browsed) consume a lot of RAM. For regular files JFFS2 needs to
store in RAM fragment trees (\texttt{jffs2\_node\_frag} and
\texttt{jffs2\_full\_dnode} objects) and for directories -- children
-lists (\texttt{jffs2\_full\_dirent} objects). Larger file you open, more
+lists (\texttt{jffs2\_full\_dirent} objects). Larger file is opened, more
RAM is require for its fragtree. Larger directory (i.e., more directory
-entries it has) you browse, more RAM is needed.
+entries in it) is browsed, more RAM is needed.
\item[Peak RAM usage.] The JFFS2 memory consumption also depends on how data is
written. Each transaction goes directly to Flash (through the
-write-buffer for page-based Flashes like NAND), i.e., there is
-Write-Through cache in Linux/JFFS2. Consequently, small transactions
+\mbox{write-buffer} for \mbox{page-based} Flashes like NAND), i.e., there is
+\mbox{Write-Through} cache in Linux/JFFS2. Consequently, small transactions
result in a great deal of small nodes on Flash and hence, much memory is required,
-for in-core objects and fragtree. Later small nodes will be merged by
+for \mbox{in-core} objects and fragtree. Later small nodes will be merged by
GC (maximum \texttt{PAGE\_SIZE} bytes of a files' data may be stored in
one node) and the amount of consumed memory will be much lower. But the peak
JFFS2 memory usage is very high.
@@ -214,18 +215,7 @@
The slow mount is the most prominent and upsetting JFFS2 feature. The
reason is, again, the JFFS2 design which doesn't assume any definite
structure on the Flash media but instead, makes use of one big log made
-up of nodes -- the only JFFS2 on-flash data structure. This design
-provides several very nice JFFS2 features as:
-\begin{itemize}
-\item very economical flash usage -- data usually takes as much flash
-space as it actually need, without wasting much space as in case of
-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 natural unclean reboot robustness;
-\end{itemize}
-
+up of nodes -- the only JFFS2 \mbox{on-flash} data structure.
But unfortunately, there are several drawbacks, for example -- slow mount.
Because of absence of any Flash structure, JFFS2 needs to scan the whole
Flash partition to identify all nodes and to build the file system map. This
@@ -233,29 +223,28 @@
To increase the mount speed JFFS2 performs as few work as possible during
the mount process and defers
-a considerable amount of work to GC thread. GC thread continues
-working in background (this process is called "checking" in JFFS2 as it
+a considerable amount of work to the GC thread. The GC thread
+works in background (this process is called "checking" in JFFS2 as it
mostly check nodes' CRC checksums, albeit it also discovers obsolete
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 cumber-stone.
+additional \mbox{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.
+order to recognize nodes, build \mbox{per-block} and \mbox{per-inode} nodes lists, etc.
\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.
+inodes which results in flash \mbox{re-reading}, eats a lot of CPU cycles and may block
+writers for a considerable time interval.
\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}.
+The first problem may be solved by a patch referred to as a "summary patch" and
+accessible at \url{http://www.inf.u-szeged.hu/jffs2/}.
%
% Inode build
@@ -263,7 +252,7 @@
\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
+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).
@@ -278,6 +267,26 @@
TODO: provide some real numbers here
+\subsection{Conclusion}
+Historically, JFFS2 was designed for small NOR flash chips and didn't even
+support NAND, whose support was added later. The JFFS2 is perfectly good for
+small flashes, and has such nice characteristics as:
+
+\begin{itemize}
+\item very economical flash usage -- data usually takes as much flash
+space as it actually need, without wasting much space as in case of
+"traditional" file systems for block devices;
+\item admitting of very efficient utilizing of "on-flight" compression which
+allows to fit a big deal of data to Flash;
+\item quick read and write operations;
+\item natural unclean reboot robustness;
+\item good wear-leveling.
+\end{itemize}
+
+But unfortunately, it has one big drawback - bad scalability. Namely, mount
+time, memory consumption and inode build time are liner functions of the
+amount of the stored data.
+
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
More information about the linux-mtd-cvs
mailing list