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

Sun Nov 13 07:47:36 EST 2005

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

Modified Files:
	JFFS3design.tex 
Log Message:
Various minor fixes of the text.



Index: JFFS3design.tex
===================================================================
RCS file: /home/cvs/mtd/Documentation/jffs3/JFFS3design.tex,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26

--- JFFS3design.tex	12 Nov 2005 12:27:23 -0000	1.25
+++ JFFS3design.tex	13 Nov 2005 12:47:32 -0000	1.26
@@ -1,8 +1,4 @@
-%
-% JFFS3 design issues.
-%
-% Copyright (C) 2005 Artem B. Bityuckiy, dedekind at infradead.org
-%
+
 % $Id$
 %
 
@@ -778,8 +774,10 @@
 \begin{enumerate}
 
 \item \emph{Data} objects contain files' data and are kept in \emph{data
-nodes}. Data nodes mainly hold one \mbox{RAM page} size of data (i.e., mainly
-4K), but for small files and for files' tails there may be less data.
+nodes}. Each data node holds one \mbox{RAM page} bytes of data (i.e.,
+\texttt{PAGE\_SIZE} which is 4K on most \mbox{32-bit} architextures). But of
+course, for small files (less then one RAM page bytes) and for files' tails
+there may be less data.
 
 %
 % Figure with an data objects illustration
@@ -798,12 +796,19 @@
 \end{figure}
 
 Figure \ref{ref_FigureDataObj-01} illustrates the correspondence between files'
-contents and data objects. Because of compression the actual data size of
+contents and data objects. Each \mbox{RAM~page-size} piece of a 13K file
+corresponds to a data node in the JFFS3 tree. The 1K tail of the file also
+corresponds to a data node. Because of compression the actual size of
 data nodes is less then the corresponding file fragments.
 
-Also, in order to optimize flash utilization, it is possible in JFFS3 that for
-large rarely changed files' there are multiple of \mbox{RAM page} bytes of data
-in one data node.
+The division on \mbox{RAM~page-sized} fragments relates to the Linux Virtual
+Memory Management architecture. Namely, the Linux \emph{Page Cache} works in
+terms of RAM pages which means, that JFFS3 is always asked to read and write
+files' in units of RAM page size.
+
+It is worth noting that in order to optimize flash utilization, JFFS3 may store
+multiple of \mbox{RAM page} bytes in one data node for static files. This
+admits of better compression and leads to several other benefits.
 
 \item \emph{Direntry} objects contain the correspondence between directory
 entry names and inode numbers. Direntry objects are stored in \emph{direntry
@@ -816,31 +821,32 @@
 etc. Each inode has only one corresponding \mbox{attr-data} object.
 
 \item \emph{Xentry} objects contain the correspondence between names of
-extended attributes and \emph{xattr~IDs} (analogous to direntry objects, but
-there is \{xattr~name$\Leftrightarrow$xattr~ID\} mapping instead of
-\{direntry~name$\Leftrightarrow$inode~number\} mapping in the xentry). Each
-extended attribute in the JFFS3 file system has its own unique number, just
+extended attributes and \emph{xattr~IDs}. Every extended attribute in the file
+system has a corresponding xattr entry object. This is analogous to direntry
+objects, but direntries contain \{xattr~name$\Leftrightarrow$xattr~ID\} mapping
+instead of \{direntry~name$\Leftrightarrow$inode~number\} mapping in xentries.
+
+Each extended attribute in JFFS3 has its own unique number~-- xattr~ID, just
 like every inode has its own unique inode number. And in fact, JFFS3 utilizes
-the same space of numbers to enumerate inodes and extended attributes. Every
-extended attribute in the file system has a corresponding xattr entry object.
+the same space of numbers to enumerate inodes and extended attributes. 
 
 Xentry objects are stored in \emph{xentry nodes}.
 
 \item \emph{Xattr-data} objects contain the data of extended attributes. The
 way how \mbox{xattr-data} objects are kept in the tree is equivalent to the way
-how data objects a kept. \emph{Xattr-data} objects are stored in
+how data objects a kept there. \emph{Xattr-data} objects are stored in
 \emph{xattr-data} nodes.
 
-\item \emph{Acl} objects contain Access Control Lists (ACL) of inodes (refer to
-[\ref{ref_ACL}] for information about ACLs). Acl objects are stored in
-\emph{acl nodes}.
+\item \emph{Acl} objects contain Access Control Lists (ACL) of inodes
+(information about ACLs may be found out at [\ref{ref_ACL}]). Acl objects are
+stored in \emph{acl nodes}.
 
 In \mbox{real-world} systems a lot of files have equivalent ACL while only few
 files have unique ACL. For the former group of files (or more strictly~--
 inodes) JFFS3 makes use of \emph{shared~acl} objects. This means, that there is
 only one acl object instance for all of these inodes. Shared acls are referred
 to from \mbox{attr-data} objects of these inodes. If a shared acl is written
-to, new acl object is created (\mbox{copy-on-write} mechanism). Conversely, for
+to, a new acl object is created (\mbox{copy-on-write} mechanism). Conversely, for
 the latter group there is a distinct acl object per each inode.
 
 \end{enumerate}
@@ -1138,7 +1144,9 @@
 management scheme scales logarithmically.
 
 Table \ref{ref_TableNANDLevels} shows the value of $m$ for different types of
-existing NAND flashes.
+existing NAND flashes (see [\ref{ref_TOSHIBA_TC58DVM92A1FT}],
+[\ref{ref_TOSHIBA_TH58NVG1S3AFT05}], [\ref{ref_STMICRO_NAND08GB}],
+[\ref{ref_SMSUNG_K9K1G08X0B}]).
 
 \begin{table}[h]
 \begin{center}
@@ -1332,6 +1340,8 @@
 \item \textbf{Acl}~-- an object in the tree containing inode's ACL. Refer to
 section \ref{ref_SectionObjects} for more information.
 
+\item \textbf{Acl node}~-- a leaf node containing an acl object.
+
 \item \textbf{Anchor eraseblock, anchor area}~-- the second and the third
 \emph{good} eraseblocks of the JFFS3 partition which are reserved for the
 superblock management. See section \ref{ref_SectionSBAlg} for more details.
@@ -1341,6 +1351,9 @@
 attributes like the type of compression, etc). Refer to section
 \ref{ref_SectionObjects} for more information.
 
+\item \textbf{Attr-data node}~-- a leaf node containing an \mbox{attr-data}
+object.
+
 \item \textbf{$B$-tree}~-- a balanced search tree where each node has many
 children. See section \ref{ref_SectionBTrees}.
 
@@ -1361,19 +1374,15 @@
 \item \textbf{Clean eraseblock}~-- an eraseblock which contains no garbage, only
 valid information.
 
-\item \textbf{Directory entry, direntry}~-- basically an association between
-the name and the inode number. As any other object direntries are stored at the
-leaf level of the tree in direntry nodes.
+\item \textbf{Data area}~-- the whole JFFS3 partition excluding the static
+superblock and anchor eraseblocks.
 
-\item \textbf{Erasable block, eraseblock}~-- the minimal erasable unit of the
-flash chip from the JFFS3's viewpoint.
+\item \textbf{Data node}~-- a leaf node with file's data.
 
-\item \textbf{Extended attributes, xattr}~-- an association between names and
-data for files and directories. See attr(5) Linux manual pages for more
-information.
+\item \textbf{Directory entry, direntry}~-- basically an association between
+the name and the inode number.
 
-\item \textbf{Data area}~-- the whole JFFS3 partition excluding the static
-superblock and anchor eraseblocks.
+\item \textbf{Direntry node}~-- a leaf node containing a direntry object.
 
 \item \textbf{Dirt, dirty space}~-- information on flash which is not valid due
 to \mbox{out-of-place} updates or objects deletion. It is the aim if the
@@ -1384,6 +1393,13 @@
 
 \item \textbf{Dirty sector}~-- a sector which contains dirt.
 
+\item \textbf{Erasable block, eraseblock}~-- the minimal erasable unit of the
+flash chip from the JFFS3's viewpoint.
+
+\item \textbf{Extended attributes, xattr}~-- an association between names and
+data for files and directories. See attr(5) Linux manual pages for more
+information.
+
 \item \textbf{Fanout}~-- the same as \textbf{branching factor}.
 
 \item \textbf{Free eraseblock}~-- an erased eraseblock (contains only
@@ -1438,6 +1454,10 @@
 Leaf nodes contain only data and do not further refer other nodes. For more
 information see section \ref{ref_SectionIndexing}.
 
+\item \textbf{NAND page}~-- a basic input output unit of NAND flash chips. ECC
+is calculated on the \mbox{per-NAND} page basis. See any NAND flash manual for
+more details, e.g., \ref{ref_TOSHIBA_TC58DVM92A1FT}.
+
 \item \textbf{Node}~-- a pile of the tree (the tree consists of nodes) as well
 as the container for file system data. There are different types of nodes in
 JFFS3. For more information see section \ref{ref_SectionIndexing}.
@@ -1450,6 +1470,10 @@
 instead, is written to some other place and the previous contents is treated as
 garbage afterwords. Opposite to \mbox{in-place} updates.
 
+\item \textbf{RAM page}~-- an unit of memory management in Virtual
+Memory Management subsystem of most modern operating systems (including Linux).
+See [\ref{ref_VM}] for more information.
+
 \item \textbf{Sector}~-- the smallest writable unit of the \emph{flash chip}
 from JFFS3's viewpoint. May be equivalent to the minimal physical input/output
 unit (like in case of NAND flashes) or larger (like in case of NOR flashes).
@@ -1502,10 +1526,15 @@
 \item \textbf{Xattr-data}~-- an object in the tree containing the data of an
 extended attribute.
 
+\item \textbf{Xattr-data node}~-- a leaf node containing an \mbox{attr-data}
+object.
+
 \item \textbf{Xentry}~-- an object in the tree which stores the association
 between the name of an extended attribute and its xattr~ID. Refer to section
 \ref{ref_SectionObjects} for more information.
 
+\item \textbf{Xentry node}~-- a leaf node containing a xentry object.
+
 \end{enumerate}
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@@ -1598,32 +1627,53 @@
 \begin{enumerate}
 
 \item \raggedright \label{ref_JFFSdwmw2}
-JFFS : The Journalling Flash File System,\\
+JFFS : The Journalling Flash File System,
 \url{http://sources.redhat.com/jffs2/jffs2-html/}
 
 \item \raggedright \label{ref_LFS}
-The Design and Implementation of a Log-Structured File System,\\
+The Design and Implementation of a Log-Structured File System,
 \url{http://www.cs.berkeley.edu/~brewer/cs262/LFS.pdf}
 
 \item \raggedright \label{ref_LaFS}
-Who wants another filesystem?,\\
+Who wants another filesystem?,
 \url{http://cgi.cse.unsw.edu.au/~neilb/conf/lca2003/paper.pdf}
 
 \item \raggedright \label{ref_SamsungNANDlist} 
-Samsung Flash memory products,\\
+Samsung Flash memory products,
 \url{http://www.samsung.com/Products/Semiconductor/Flash/index.htm}
 
 \item \raggedright \label{ref_Reiser4}
-Reiser4 File System, \url{http://www.namesys.com/}
+Reiser4 File System,
+\url{http://www.namesys.com/}
 
 \item \raggedright \label{ref_ACL}
-POSIX Access Control Lists on Linux
+POSIX Access Control Lists on Linux,
 \url{http://www.suse.de/~agruen/acl/linux-acls/}
 
 \item \raggedright \label{ref_Quota}
-Quota mini-HOWTO
+Quota mini-HOWTO,
 \url{http://www.tldp.org/HOWTO/Quota.html}
 
+\item \raggedright \label{ref_VM}
+Wikipedia: Virtual Memory,
+\url{http://en.wikipedia.org/wiki/Virtual_memory}
+
+\item \raggedright \label{ref_TOSHIBA_TC58DVM92A1FT}
+Toshiba TC58DVM92A1FT NAND flash chip,
+\url{http://www.toshiba.com/taec/components/Datasheet/TC58DVM92A1FT_030110.pdf}
+
+\item \raggedright \label{ref_TOSHIBA_TH58NVG1S3AFT05}
+Toshiba TH58NVG1S3AFT05 NAND flash chip,
+\url{http://www.toshiba.com/taec/components/Datasheet/TH58NVG1S3AFT05_030519A.pdf}
+
+\item \raggedright \label{ref_STMICRO_NAND08GB}
+ST-micro NAND08G-B NAND flash chip,
+\url{http://www.st.com/stonline/products/literature/ds/11241.pdf}
+
+\item \raggedright \label{ref_SMSUNG_K9K1G08X0B}
+Samsung K9K1G08X0B NAND flash chip,
+\url{http://www.samsung.com/Products/Semiconductor/NANDFlash/SLC_SmallBlock/1Gbit/K9K1G08U0B/ds_k9k1g08x0b_rev02.pdf}
+
 \end{enumerate}
 
 \end{document}



