mtd/fs/jffs3 JFFS3design.tex,1.42,1.43

Artem Bityuckiy dedekind at infradead.org
Sat Apr 23 08:33:52 EDT 2005


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

Modified Files:
	JFFS3design.tex 
Log Message:
Update DCP chapter.

Index: JFFS3design.tex
===================================================================
RCS file: /home/cvs/mtd/fs/jffs3/JFFS3design.tex,v
retrieving revision 1.42
retrieving revision 1.43
diff -u -r1.42 -r1.43
--- JFFS3design.tex	22 Apr 2005 17:18:39 -0000	1.42
+++ JFFS3design.tex	23 Apr 2005 12:33:49 -0000	1.43
@@ -352,7 +352,7 @@
 \begin{itemize}
 \item GC and file change speed optimization -- we update only few DCP nodes if
 a large file is being changed or one of its nodes is being GCed;
-\item memory consumption optimization -- we don't need to keep in-core
+\item memory consumption optimization -- JFFS3 doesn't need to keep in-core
 the DCP ranges;
 \item DCP composing optimization -- DCP entries are sorted and
 it is much faster to sort short arrays rather then long.
@@ -374,14 +374,14 @@
    * DCP. The array is sorted by the node range offset in
    * ascending order. */
   struct jffs3_dcp_entry entries[];
-}
+} __attribute__((packed));
 
 struct jffs3_dcp_entry
 {
   uint32_t phys_offs; /* The position of the node on Flash. */
   uint32_t offs;      /* Offset of the data range the node refers. */
   uint16_t len;       /* The length of the node data range. */
-}
+} __attribute__((packed));
 \end{verbatim}
 
 The value of the DCP range $R_{DCP}$ depends on various aspects:
@@ -392,8 +392,12 @@
 flash size. Nonetheless, this will make troubles when moving an JFFS3
 image from small flash to large.
 
+From the other hand, very large $R_{DCP}$ implies large physical
+DCP nodes size and slower DCP updates.
+
 \item[RAM page size.] Obviously $R_{DCP}$ must be multiple of
-\texttt{PAGE\_SIZE}, and to facilitate JFFS3 portability we should
+\texttt{PAGE\_SIZE}, and to facilitate JFFS3 portability in the case of
+removable devices, we should
 make it multiple of the largest 64~KiB \texttt{PAGE\_SIZE}
 used in Linux our days. 4 KiB should be treated as the smallest possible
 RAM page size.
@@ -402,25 +406,24 @@
 neither too large nor too small. To facilitate faster DCP update on NAND
 flashes the maximum DCP node physical size $S_{DCP}$ should be one NAND
 page.
-One DCP entry takes 6 bytes and the DCP header takes 32 bytes and it is
-easy to calculate the maximum number DCP entries $E_{DCP}$ if DCP node
-size would be limited to one NAND page:
+One DCP entry takes 10 bytes, the DCP node header takes 16 bytes and it is
+easy to calculate the maximum number DCP entries $E_{DCP}$:
 \begin{center}
 \begin{tabular}{ll}
 \textbf{NAND page size} & $\bf E_{DCP}$ \\
 \hline
-512 bytes  & 80\\
-2048 bytes & 336\\
-4096 bytes & 667\\
+512 bytes  & 49\\
+2048 bytes & 203\\
+4096 bytes & 408\\
 \end{tabular}
 \end{center}
 
-\item[Largest data node size.] To gain write performance JFFS3 should be
+\item[Largest data node size.] To gain the write performance JFFS3 should be
 able to write non-pristine nodes, i.e., nodes of size <
 \texttt{PAGE\_SIZE}. In order to allow filling the DCP range by
 non-pristine nodes the following should be true:
-$$R_{DCP} > R_{data}{\cdot}E_{DCP},$$
-where $R_{data}$ is the maximal data node range and $E_{DCP}$ is the
+$$R_{DCP} > \tt{PAGE_SIZE}{\cdot}E_{DCP},$$,
+where $E_{DCP}$ is the
 maximal number of DCP entries in DCP. The table below illustrates
 the average data node range size depending on $R$ and NAND page size.
 
@@ -429,9 +432,8 @@
 \begin{tabular}{ll}
 $\bf R_{DCP}$ & \textbf{Average $\bf R_{data}$}\\
 \hline
-64 KiB  & 820 bytes\\
-128 KiB & 1.64 KiB\\
-256 KiB & 3.28 KiB\\[4pt]
+64 KiB  & 1.3 KiB\\
+128 KiB & 2.7 KiB\\
 \end{tabular}
 \end{center}
 
@@ -440,9 +442,9 @@
 \begin{tabular}{ll}
 $\bf R_{DCP}$ & \textbf{Average $\bf R_{data}$}\\
 \hline
-256 KiB & 780 bytes\\
-512 KiB & 1.56 KiB\\
-1 MiB   & 3.12 KiB\\[4pt]
+128 KiB & 645 bytes\\
+256 KiB & 1.3 KiB\\
+512 KiB & 2.6 KiB\\
 \end{tabular}
 \end{center}
 
@@ -451,31 +453,45 @@
 \begin{tabular}{ll}
 $\bf R_{DCP}$ & \textbf{Average $\bf R_{data}$}\\
 \hline
-512 KiB & 790 bytes\\
-1 MiB   & 1.57 KiB\\
-2 MiB   & 3.14 KiB\\
+256 KiB & 642 bytes\\
+512 KiB & 1.3 KiB\\
+1 MiB   & 2.6 KiB\\
 \end{tabular}
 \end{center}
+
+The above tables assume each DCP entry may at most refer 4~KiB of data.
+Thus we guarantee that DCP node won't be larger then one NAND page.
+
+For NOR and other non-paged flashes JFFS3 just assumes some that
+the flash page size is 512 bytes or larger, depending on the
+flash size.
 \end{description}
 
-Keeping in-core references to all the DCP nodes of a
-file may eat much RAM. Assuming that we keep in-core only 4~byte DCP
-flash addresses (which is in fact unreachable) we have:
+If we keep in RAM references of all the DCP nodes of a file, we may
+waste much RAM.  Assuming that each reference takes 4~bytes
+(which is in fact unreachably few) we have:
 
 \begin{center}
-\begin{tabular}{llll}
+\begin{tabular}{lllll}
 \textbf{File size} & \textbf{NAND Page size} &
-$\bf R_{DCP}$ & \textbf{RAM required}\\
+$\bf R_{DCP}$ & \textbf{RAM required} &
+\textbf{Flash overhead}\\
 \hline
-64 MiB  & 512 bytes  & 256 KiB & 1 MiB\\
-1 GiB   & 2048 bytes & 1 MiB   & 4 MiB\\
-8 GiB   & 4096 bytes & 2 MiB   & 8 MiB\\
+64 MiB  & 512 bytes  & 128 KiB & 2 MiB  & 256 KiB (0.4\%)\\
+1 GiB   & 2048 bytes & 512 KiB & 8 MiB  & 4 MiB (0.4\%)\\
+8 GiB   & 4096 bytes & 1 MiB   & 32 MiB & 16 MiB (0.4\%)\\
 \end{tabular}
 \end{center}
 
-To relax this JFFS3 uses \emph{second level data checkpoints} (DCP2) referring
-the level one data checkpoints of the file. Similarly to DCP, DCP2
-constraints are:
+The above table also shows the amount of Flash space required to store
+DCP nodes (assuming each DCP entry takes the whole Flash page).
+
+
+To relax RAM usage JFFS3 makes use of \emph{second level data
+checkpoints} (DCP2) referring
+the level one data checkpoints of the file similerly to how DCP refers
+data nodes. The following requirements are to be met for DCP2:
+
 \begin{itemize}
 \item DCP2 range $R_{DCP2}$ is multiple of DCP range $R_{DCP}$;
 \item the largest DCP2 node physical size $S_{DCP2}$ is limited by the
@@ -488,13 +504,12 @@
 \textbf{File size} & \textbf{NAND Page size} &
 $\bf R_{DCP}$ & \textbf{RAM required}\\
 \hline
-64 MiB  & 512 bytes  & 256 KiB & 12 bytes\\
-1 GiB   & 2048 bytes & 1 MiB   & 12 bytes\\
-8 GiB   & 4096 bytes & 2 MiB   & 24 bytes\\
+64 MiB  & 512 bytes  & 256 KiB & 44 bytes\\
+1 GiB   & 2048 bytes & 1 MiB   & 44 bytes\\
+8 GiB   & 4096 bytes & 2 MiB   & 84 bytes\\
 \end{tabular}
 \end{center}
 
-TODO: but the real picture is not so nice... more complications needed...
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %





More information about the linux-mtd-cvs mailing list