mtd/fs/jffs3 JFFS3design.tex,1.30,1.31

[gleixner at infradead.org]

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

Modified Files:
	JFFS3design.tex 
Log Message:
Minor fixes and some additional comments here and there

Index: JFFS3design.tex
===================================================================
RCS file: /home/cvs/mtd/fs/jffs3/JFFS3design.tex,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -r1.30 -r1.31
--- JFFS3design.tex	26 Mar 2005 13:14:03 -0000	1.30
+++ JFFS3design.tex	26 Mar 2005 14:24:34 -0000	1.31
@@ -166,7 +166,7 @@
 unimportant although it should be kept in mind during JFFS3
 implementation.
 
-Conceivably, JFFS3 might try to find older obsolete node
+Conceivably, JFFS3 might try to find an older obsolete node
 containing the corrupted information as well as to reconstruct the
 corrupted data using the corresponding in-memory data if it is present.
 The recovery is especially important in case of corrupted direntry node
@@ -187,12 +187,24 @@
 % VIRTUAL BLOCK HANDLING
 %
 \section{Virtual Block handling}
-The concatenation of blocks to virtual blocks must deal with
-bad blocks in the virtual block rather than treating the
-whole virtual block as bad (as it is done in JFFS2).
-Therefore JFFS3 must treat the blocks inside a virtual block seperately.
-This implies the clean marker write per physical block after erase and
-the limitation of writes to physical block boundaries.
+To reduce memory consumption for block references JFFS3 can
+concatenate several physical erase blocks into a virtual erase block.
+
+Virtual erase blocks have also disadvantages. The bigger size affects
+garbage collection as larger entities have to be handled, which
+degrades GC efficency and performance.
+
+In order to keep accounting simple the number of concatenated blocks
+must be a power of two.
+
+The concatenation must be configurable by the user.
+
+The concatenation of physical blocks to virtual blocks must deal with
+bad blocks in the virtual block rather than treating the whole virtual
+block as bad as it is currently done in JFFS2. Therefor JFFS3 must treat the
+physical blocks inside a virtual block seperately. This implies the
+clean marker write per physical block after erase and the limitation
+of writes to physical block boundaries.
 
 A nice benefit is that this keeps the File System compatible for different
 concatenation settings in case of removable media.
@@ -219,22 +231,22 @@
 \item \texttt{struct list\_head *used\_blocks[HASH\_SIZE];}
 \end{itemize}
 
-For the current max. chipsizes we have max. 32678 blocks / chip. We
-assume an \texttt{HASH\_SIZE} of 256 for now. The wear leveling makes it
+For the current max. chipsizes we have max. 32678 blocks / chip. An
+\texttt{HASH\_SIZE} of 256 is assumed for now. The wear leveling makes it
 necessary to enqueue the blocks in order into the hash array. This
 sounds complicated and time consuming, but it is not.
 
 The maximum guaranteed erase cycles for NAND and NOR are ~ 100K at the
-moment. We assume a best case maximum of 256K and build the hash index
-by shifting the erase count 10 times right and putting the block at
-the end of the hash entry list. So the variance of the erase counts in
-one entry is max. 1024, which is reasonable. This enqueueing lets us
-pick used blocks with static unchanged data for garbage collection on
-purpose to bring the blocks back into use. The garbage collection in
-such a case is simply copying the whole block to a block from the free
-list. Newer NAND Flash supports on chip page copying. This feature
-should be made available in the MTD Kernel API to enhance performance
-of such operations.
+moment. A best case maximum of 256K is assumed and the hash index is
+built by shifting the erase count 10 times right and putting the block
+at the end of the hash entry list. So the variance of the erase counts
+in one entry is max. 1024, which is reasonable. This enqueueing makes
+it possible to pick blocks with static unchanged data for garbage
+collection on purpose to bring the blocks back into use. The garbage
+collection in such a case is simply copying the whole block to a block
+from the free list. Newer NAND Flash supports on chip page
+copying. This feature should be made available in the MTD Kernel API
+to enhance performance of such operations.
 
 %
 % BLOCK REFERENCE
@@ -242,17 +254,16 @@
 \section{Blocks reference}
 
 The JFFS2 block accounting variables (see [\ref{ref_JFFS2_blk_ref}])
-can mostly go away. The information can be
-held in one variable, if it is stored depending on the block
-state. The possibility to have accounting control via the distinct
-variables could be kept for debugging purposes, but not for production
-use.
-
-It's not necessary to hold the current block being GCed (\texttt{gc\_node} JFFS2's field)
-in the block reference. The garbage collector recycles only one block at a time, so
+can mostly go away. The information can be held in one variable, if it
+is stored depending on the block state. The possibility to have
+accounting control via the distinct variables could be kept for
+debugging purposes, but not for production use.
+
+It's not necessary to hold the garbage collectors current node
+reference (\texttt{gc\_node} JFFS2's field) in the block reference
+structure. The garbage collector recycles only one block at a time, so
 this is an information which can be held in the garbage collector or
-in the global file system data if other parts need to have access to
-it.
+in the global file system data if other parts must have access to it.
 
 The first/last node pointers should be reduced to one. This depends on the
 final node reference design, check pointing, summary nodes etc.
@@ -291,7 +302,7 @@
 NAND 2GiB 64k block size   & 512 kiB\\
 \end{tabular}\\
 
-This is 4 times the size of the current limit. This can be cut down
+This is 4 times the size of the current limit. It can be cut down
 below 128K by concatenating of 4 physical blocks to a virtual
 block. The above mentioned disadvantages of virtual blocks still
 apply, but degraded by factor 4. The concatenation should be made
@@ -323,10 +334,6 @@
 blocks. This results in 12 blocks per virtual block,
 which are rounded up to 16 to utilize $2^n$ operations.
 
-Virtual eraseblocks have disadvantages. The bigger size affects
-garbage collection as larger entities have to be handled, which
-degrades GC efficency and performance.
-
 The current JFFS2 erase block structure is defined as follows:
 
 \begin{verbatim}
@@ -354,26 +361,26 @@
 It is proposed to enlarge the maximal data node size to effect several
 enhancements (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:
+JFFS3's maximal data size is multiple of \texttt{PAGE\_SIZE}. As a
+first measure 4-8 memory pages seems to be a 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 The physcial block size. Nodes must not exceed the physical block size 
+to allow the configurable selection of block concatenation in virtual blocks.
+
+\item Nodes can not be written over physical block boundaries.
 
 \item read latency - large nodes may lead to substantial read latency
-since JFFS3 will need to reed and uncompress more
-information at once.
+since JFFS3 will need to read and uncompress more information at once.
 \end{itemize}
 
 Consequently, 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 propagating the
-Page Cache. By another words, if the data node being read contains several RAM
+page in the \texttt{read\_page()} operation, but more pages thus propagating the
+Page Cache. By other 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.
@@ -419,9 +426,9 @@
 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):
+Pristine nodes are pretty good idea from the performance's viewpoint
+but have some substantial disadvantages compared to the data nodes
+of larger size:
 
 \begin{itemize}
 \item the compression ratio is worse when small data chunks are compressed;