mtd/fs/jffs3 JFFS3design.tex,1.25,1.26

[Artem Bityuckiy]

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

Modified Files:
	JFFS3design.tex 
Log Message:
Add new chapter discussing the data node size.
Add more definitions.
Fix some typos.



Index: JFFS3design.tex
===================================================================
RCS file: /home/cvs/mtd/fs/jffs3/JFFS3design.tex,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- JFFS3design.tex	26 Feb 2005 14:54:26 -0000	1.25
+++ JFFS3design.tex	1 Mar 2005 11:43:23 -0000	1.26
@@ -54,11 +54,12 @@
 
 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.
+like). Errors fall into the following categories.
 
 \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
 block has been erased.
 \end{itemize}
@@ -90,7 +91,6 @@
 \item \emph{AND} (\emph{AG-AND} and \emph{SuperAND}),
 like NAND technology, implies bad blocks either factory marked
 or dynamically found [\ref{ref_RenesasAND}].
-
 \end{itemize}
 
 %
@@ -155,7 +155,6 @@
 
 \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}
 
 %
@@ -185,6 +184,93 @@
 generate redundant adler32 checksum for better performance.
 
 %
+% MAXIMAL SIZE OF INODE NODE DATA
+%
+\section{Maximal size of inode node data}
+It is proposed to enlarge the maximal data node size to effect several
+enchancements (see \ref{ref_BackgroundInformation} for more details).
+
+JFFS3's maximal data size is multiple of \texttt{PAGE\_SIZE}. At the
+first glance 4-8 pages is sane amount, although this depends on several
+aspects:
+
+\begin{itemize}
+\item vblock size - nodes must not exceed the vblock size; furthermore, there
+could be few space left in the vblock so JFFS3 should flexibly adjust the number of
+\texttt{PAGE\_SIZE}-sized chunks in the data node being written.
+
+\item read latency - large nodes may lead to substantial read latency
+since JFFS3 will need to reed and uncompress more
+information at once.
+\end{itemize}
+
+Concequently, the maximal size of the data node's data has to be configurable.
+
+To facilitate efficient data node reading we propose to use the method which is
+exploited by ZISOFS filesystem. Basically, the idea is to read not exactly one
+page in the \texttt{read\_page()} operation, but bore pages thus propogating the
+Page Cache. By another words, if the data node being read contains several RAM
+pages of data we might read them all into the Page Cache at once. With this we
+will still have good read performance since we don't need to introduce
+additional intermediate buffers.
+
+%
+% Background information
+%
+\subsection{Background information} \label{ref_BackgroundInformation}
+JFFS2 limits the maximal size of the inode node data to the size of the
+RAM page that is often 4KiB. To put it differently, JFFS2 looks at the 
+\texttt{PAGE\_SIZE} constant to determine the maximal size of the inode
+node data.
+
+JFFS2 inode node's data doesn't have to be 4KiB -- it might
+have fewer bytes. In fact, all the user write operations go directly to
+flash as JFFS2 doesn't cache them (JFFS2 has write-through cache).
+Hence, the size of inode node data is affected by user-space
+programs which issue actual write operations.
+
+According to the size of data, all the inode nodes in JFFS2 fall into
+two types:
+
+\begin{itemize}
+\item \emph{pristine nodes} -- which carry \texttt{PAGE\_SIZE} bytes of
+uncompressed data;
+
+\item \emph{non-pristine nodes} -- which carry less data.
+\end{itemize}
+
+Originally most data nodes are non-pristine, but GC merges them
+producing pristine nodes. This work coincides with actual garbage
+collection and might be regarded as an ancillary albeit important
+optimization activity.
+
+The above mentioned distinction is dictated by Linux architecture. In
+particular, by the Linux Page Cache that works on per-page basis. I.e.,
+JFFS2 is asked to read data from files by fractions of
+\texttt{PAGE\_SIZE} bytes. Obviously, the easiest way to form the
+requested RAM page of data is to read it directly from flash (and
+perhaps, to uncompress) to the RAM page. When the file data
+corresponding to the requested RAM page is
+scattered over several nodes, the task becomes a bit more complex. And
+it is much more complex when the data is scattered over several nodes
+and compressed.
+
+Pristine nodes are pretty good idea from the performance's viewpoint but has
+some substantial disadvantages (comparing to the data nodes of larger
+size):
+
+\begin{itemize}
+\item the compression ratio is worse when small data chunks are compressed;
+
+\item each data node involves some additional flash space overhead
+because of its header;
+
+\item JFFS2 needs more RAM to keep track of nodes; this is the worst
+drawback, see (TODO) for more information about this JFFS2 and JFFS3.
+\end{itemize}
+
+
+%
 % ABBREVIATIONS
 %
 \section{Abbreviations}
@@ -210,6 +296,8 @@
 that new bad blocks may appear during the flash's life-cycle. These blocks
 have to be marked bad too.
 
+\item \emph{Data node} -- the inode node relating to file, not to directory.
+
 \item \emph{Direntry node} -- node representing JFFS3 directory entry.
 Each JFFS3 directory entry is represented by one valid direntry node.
 
@@ -230,9 +318,12 @@
 stored in form of node(s). There are different types of nodes defined.
 
 \item \emph{Node header} --
-node and the relative data structure consists of two main data parts - header and
+node and the relative data structure largely consists of two parts - header and
 data. Node header contains internal information while node data contains some
-user-visible data like file's content or name.
+user-visible data like file's content or direntry's name.
+
+\item \emph{Non-pristine node} -- a type of data node which containes the amount
+of uncompressed data which is not multiple of \texttt{PAGE\_SIZE} bytes.
 
 \item \emph{Inode node} -- node representing JFFS3 inode.
 Any inode in JFFS3 is represented by one (for directory inodes) or more
@@ -248,6 +339,9 @@
 any meaningful node. Padding nodes facilitate the faster filesystem
 scanning.
 
+\item \emph{Pristine node} -- a type of data node which contain multiple of
+\texttt{PAGE\_SIZE} bytes of data in the uncompressed form.
+
 \item \emph{Summary node, summary} --
 describes the layout of full vblock. Summary is  situated at the end
 of each vblock and describes the vblock's layout, e.g. position, type,
@@ -326,12 +420,6 @@
 document. Many of them may be quite useful.
 
 \begin{enumerate}
-\item Have some global or per-inode flag telling that there was a checksum
-error detected. In this flag is set, print big warning saying that flash
-device in not reliable anymore. Should be controlled by user, though
-(may be using xattr).\\
-\url{http://lists.infradead.org/pipermail/linux-mtd/2005-January/011608.html}.
-
 \item Make the compression selectable per-file (may be using xattr).\\
 \url{http://lists.infradead.org/pipermail/linux-mtd/2005-January/011645.html}.