mtd/fs/jffs3 JFFS3design.tex,1.21,1.22
Artem Bityuckiy
dedekind at infradead.org
Fri Feb 25 14:07:51 EST 2005
Update of /home/cvs/mtd/fs/jffs3
In directory phoenix.infradead.org:/tmp/cvs-serv13899
Modified Files:
JFFS3design.tex
Log Message:
Reviewed. Uncompleted stuff is remporarily removed.
Index: JFFS3design.tex
===================================================================
RCS file: /home/cvs/mtd/fs/jffs3/JFFS3design.tex,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- JFFS3design.tex 14 Feb 2005 08:29:23 -0000 1.21
+++ JFFS3design.tex 25 Feb 2005 19:07:48 -0000 1.22
@@ -7,10 +7,8 @@
%
\documentclass[12pt,a4paper,oneside,titlepage]{article}
-\usepackage{longtable}
\usepackage{hyperref}
\usepackage{html}
-\usepackage{times}
\textwidth=18cm
\oddsidemargin=0cm
\topmargin=0cm
@@ -32,7 +30,7 @@
\pagestyle{empty}
\begin{abstract}
This document discusses different JFFS3 design aspects.
-Additionally, this document tries to define standard JFFS3 dicitionary and terms.
+Additionally, this document tries to define standard JFFS3 dictionary and terms.
\end{abstract}
%
@@ -48,428 +46,237 @@
Incomplete, working draft.
%
-% ABBREVIATIONS
+% CHECKSUMS
%
-\section{Abbreviations}
-\begin{longtable}{p{3cm}p{14.5cm}}
-\large \textbf{Abbrev.} & \large \textbf{Definition} \\[7pt]
-
-\emph{CRC} & Cyclic Redurancy Check \\[4pt]
-
-\emph{GC} & Garbage Collector \\[4pt]
-
-\emph{JFFS2} & Jouranlling Flash File System version 2 \\[4pt]
+\section{Checksums}
+Any data (including actual file content and internal JFFS3 data) stored within
+JFFS3 file-system is protected by checksum. Nothing is stored on the flash media
+without checksum.
+
+Checksums are destined to detect errors when flash becomes corrupted owing
+to wear, BB appearance or external factors (abnormal temperatures and the
+like). Thus, it is worth distinguishing between \emph{permanent} and
+\emph{occasional} error:
-\emph{JFFS3} & Jouranlling Flash File System version 3 \\[4pt]
+\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}
-\emph{MTD} & Memory Technology Device \\[4pt]
+Different flash technologies imply different reliability. The following is the
+brief overview of Flash technologies in this perspective.
-\emph{ICP} & Inode Check-Point \\[4pt]
+\begin{itemize}
+\item \emph{NOR}
+flash is the most trustworthy type of flashes which doesn't admit of permanent
+errors. Any permanent error is critical and means the chip is not workable anymore.
+Nevertheless, some kinds of NOR flash are not avoid of very rare bit flipping
+events and the use of checksum still might make sense here.
+
+\item \emph{DataFlash} is based on NOR technology and inherits its properties.
+[\ref{ref_AtmelDataFlash}].
+
+\item \emph{ECC NOR} may be regarded as not very robust NOR flash plus extra ECC
+protection.
+
+\item \emph{NAND} flash is not so reliable as NOR and it admits of permanent errors, let
+alone occasional ones which are also possible. The NAND technology itself
+implies bad blocks may dynamically appear during its utilization, albeit this is
+rather rare event [\ref{ref_NANDMTD}, \ref{ref_ToshibaNAND}].
+
+\item \emph{OneNAND} is based on NAND technology and has similar properties
+[\ref{ref_SamsungOneNAND}].
+
+\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{longtable}
+\end{itemize}
%
-% DEFINITIONS
+% Checksum modes
%
-\section{Definitions}
+\subsection{Checksum modes}
+Because of a significant disparity in the reliability between different types of
+flashes JFFS3 might operate in two of the following modes.
-\begin{longtable}{p{3cm}p{14.5cm}}
+\begin{enumerate}
+\item \emph{Strict mode} -- checksums are always verified i.e. anything JFFS2
+has read from flash is validated by checksum. This is safest operation mode and
+should probably always be enabled by default at least with NAND/AND flashes.
+
+\item \emph{Relaxed mode} -- data checksums are not ever being checked, i.e
+JFFS3 still checks node headers and other internal data but doesn't check actual
+file's content. This is dangerous working mode is probably can only be enabled
+by default when JFFS3 works on top of NOR flash.
+\end{enumerate}
-\large \textbf{Term} & \large \textbf{Definition}
-\\[7pt]
+Both of the above mentioned operation modes imply that JFFS3 calculates and
+saves checksums when it is performing write operations.
-\raggedright \emph{Page Cache}
-&
-The Linux Page Cache caches the disk data. This is the layer between
-the VM subsystem and various disk IO related subsystems. The disk data
-is cached by peaces of RAM page size (usually 4KiB),
-so any JFFS3 read/write operation
-is done in terms of pages. See [\ref{ref_GormanVM}] for more Linux VM
-details.
-\\[4pt]
-
-\raggedright \emph{In-core memory}
-&
-The memory that is always consumed by JFFS3 irrespective on are there opened files
-or not. This memory can not be reaped by the Linux VM subsystem and the only way
-to reclaim it is to unmount the JFFS3 fylesystem.
-The in-core memory which is consumed by JFFS3 depends lineary on
-the number of inodes (TODO: take care, not designed yet) on the flash.
-TODO: list the in-core objects data types here.
-\\[4pt]
-
-\raggedright \emph{Write buffer, wbuf}
-&
-TODO
-\\[4pt]
-
-\raggedright \emph{Block, Sector}
-&
-The minimal flash erasable unit.
-\\[4pt]
-
-\raggedright \emph{Bad block}
-&
-NAND flashes may be shipped with bad blocks. These blocks are marked
-bad and must not be never used or erased. The technology also implies
-that new bad blocks may appear during the flash's life cycle. These blocks
-may be marked bad too. See [\ref{ref_ToshibaNAND}] for more details.
-\\[4pt]
-
-\raggedright \emph{Eblock}
-&
-JFFS3 may treat several sectors as one eblock. Thus, the minimal
-erasable flash unit from the JFFS3's viewpoint is eblock which consists
-of one or more flash blocks.
-\\[4pt]
-
-\raggedright \emph{Wear-leveling}
-&
-TODO
-\\[4pt]
-
-\raggedright \emph{Garbage Collector, GC}
-&
-The Garbage Collector is very important part of JFFS3 subsystem which performs
-several tasks. The main task of the GC is reclaiming the dirty space - it moves
-all the valid nodes from dirty eblocks, thus reclaiming the space occupire by
-the dirt. Another tasks done by the GC are wear-levelling and producing pristing
-nodes.
-
-See [\ref{ref_JFFSdwmw2}] for more details about GC in JFFS2 which is pretty close
-to the GC in JFFS3.
-\\[4pt]
-
-\raggedright \emph{GC thread}
-&
-TODO
-\\[4pt]
-
-\raggedright \emph{Build inode}
-&
-TODO: iget()
-\\[4pt]
-
-\raggedright \emph{Destroy inode}
-&
-TODO: iput()
-\\[4pt]
-
-\raggedright \emph{Node}
-&
-Basic JFFS3 data structure -- anything which JFFS3 stores on flash is
-stored in form of nodes. There are different types of nodes defined.
-Nodes have standard layout -- common header, header and
-data. Common header is the same for any node type. Header and
-data sections are different for different node types.
-\\[4pt]
-
-\raggedright \emph{Node common header}
-&
-Any node begins with common header which contains node magic
-bitmask, node lenght and node type.
-\\[4pt]
-
-\raggedright \emph{Node header}
-&
-The node section next after common header. Unique for each node type.
-\\[4pt]
-
-\raggedright \emph{Node data}
-&
-The node section next after node header. Unique for each node type
-(e.g., the peace of inode data for the inode nodes, the direntry name in
-case of direntry node).
-\\[4pt]
-
-\raggedright \emph{Inode node}
-&
-Any inode in JFFS3 is represented by one (for directory inodes) or more
-(for file inodes) inode nodes. Inode nodes are
-\texttt{struct~jffs3\_raw\_inode} objects.
-\\[4pt]
-
-\raggedright \emph{Direntry node, direntry, dirent}
-&
-Each JFFS3 directory entry is represented by the direntry node.
-Direntry nodes are \texttt{struct~jffs3\_raw\_dirent} objects.
-\\[4pt]
-
-\raggedright \emph{Deletion direntry node, deletion dirent}
-&
-TODO
-\\[4pt]
-
-\raggedright \emph{Summary node, summary}
-&
-Summary node is special node type which describes the layout of
-not-empty eblocks. Summary blocks are situated at the end of each eblock
-(which contain some data) and describe the position, type, length and
-some other parameters of all the eblock's nodes. Summary nodes are
-\texttt{struct~jffs3\_raw\_summary} objects.
-
-Summary nodes are used to quickly get the information about
-the block physical layout.
-\\[4pt]
-
-\raggedright \emph{Inode checkpoint node, ICP, checkpoint}
-&
-Inode checkpoint node, or ICP node, or just checkpoint is the kind of JFFS3
-node. ICP relates to some inode and there may be several ICPs corresponding to
-one inode. ICP describes the nodes of the inode and is used to quickly aquire
-the information about an inode's nodes. Checkpoints are similar to summaries,
-but contain the per-inode information rather then per-block. ICPs are
-\texttt{struct~jffs3\_raw\_icp} objects.
-
-ICP nodes are used to quickly aquire the information about the inode's nodes.
-\\[4pt]
-
-\raggedright \emph{Padding node}
-&
-\\[4pt]
-
-\raggedright \emph{Obsolete node}
-&
-Obsolete nodes are those nodes which do not describe anything actual anymore.
-Depending on the node type, nodes become obsolete differently. For example, the
-inode node becomes obsolete when its data is not valid anymore because, for
-example, the correspondent file data range was filled by another data
-(and hence, there is another node with higher version exist). Obsolete nodes
-are treated as dirt or dirty space.
-\\[4pt]
-
-\raggedright \emph{Valid node}
-&
-Valid nodes are non-obsolete nodes.
-\\[4pt]
-
-\raggedright \emph{Obsolete inode node}
-&
-TODO
-\\[4pt]
-
-\raggedright \emph{Obsolete direntry node}
-&
-TODO
-\\[4pt]
-
-\raggedright \emph{Obsolete ICP node}
-&
-TODO
-\\[4pt]
-
-\raggedright \emph{Dirty space, dirt}
-&
-Obsolete nodes and paddings constitute dirt.
-\\[4pt]
-
-
-\raggedright \emph{Summary end magic bitmask}
-&
-Summary nodes has special
-magic bitmask at theirs end which helps to quickly detect whether the
-summary node present or not in the given eblock by reading the last few
-eblock's bytes.
+If the underlying flash makes use of ECC (e.g., NAND), and JFFS3 has been
+reported ECC error, JFFS3 checks the corresponding data that has just been read.
-\end{longtable}
+The checksum mode might be set on the per file basis with
+help of the corresponding extended attribute. In this case the extended
+attribute overrides the default mode.
%
-% CHECK SUMMS
+% Checksum and unclean reboots
%
-\section{Checksums}
-JFFS3 protects nodes by checksums.
-In order to be able to work with different node sections (common header,
-header, data) independently, each node section has its own checksum.
+\subsection{Checksum and unclean reboots}
+Unlike JFFS2, JFFS3 does not utilize checksums to detect unclean reboots, albeit
+they might be engaged. The primary aim of checksum is preventing problems
+relating to a physical media corruption. Unclean reboots are primarily
+detected by means of summary nodes. This property makes it possible to distinct
+between checksum errors caused by media problems and by unclean reboots and
+not to print a warning message in the latter case and the like.
+
+%
+% Checksum errors
+%
+\subsection{Checksum errors}
+If a checksum error has been found and if it has not been caused by
+an unclean reboot the further JFFS3 behavior depends on the underlying flash
+type:
-In JFFS3 checksums are intended to detect node corruptions. Nodes may
-become corrupted due to different reasons:
-\begin{itemize}
-\item flash wearing;
-\item external influence (abnormal temperature, radiation, etc);
-\item technology specifics, for example:
\begin{itemize}
-\item NAND technology implies that block may become bad with very small
-possibility.
-\item NAND technology implies bits flipping, but this is very rare
-phenomena either;
-\item AG-AND flash chips impliy rare bit fliping in a block if another block
-from a specific block group is erased;
-\item etc.
-\end{itemize}
+\item if the flash admits of bad blocks (NAND, etc), the erroneous node is just
+ignored since it is assumed the error is owing to new bad block;
+
+\item otherwise, JFFS3 refuses any further write requests and switches to the
+read-only mode; the erroneous node is ignored as well.
\end{itemize}
-\subsubsection*{JFFS2 correspondence}
-JFFS2 uses checksums to detect errors caused by unclean reboots (unclean
-reboot may happen any time and partially written nodes may
-appear on the flash). JFFS2 treats any checksum error as an error caused by
-unclean reboots and have no general ability to distinguish between
-checksum errors due to physical flash corruptions and due to unclean
-reboots.
-
-In general, in JFFS3 checksums are not intended (but still may be used) to detect
-errors cased by unclean reboots. There is another mechanism exists for
-this purpose (see section \ref{ref_sec_unclean_reboot}).
-
-JFFS2 prints the CRC error message to the system log on every CRC error found.
-In syctems, where unclean reboots happen very often, this is very
-annoying. JFFS3 should be implemented such a way that it does not print
-the warning messages if the found checksum error is due to unclean
-reboot.
+%
+% Miscellaneous
+%
+\subsection{Miscellaneous}
+Like JFFS2, JFFS3 makes use of CRC32 checksum algorithm with the start seed
+0xFFFFFFFF.
+
+If zlib library is used to compress node's data it is worth asking zlib not to
+generate redundant adler32 checksum for better performance.
%
-% Checksum modes
+% ABBREVIATIONS
%
-\subsection{Checksum modes}
-Two JFFS3 checksum working modes are defined and
-depending on the file type and device's goal, one of them is used.
+\section{Abbreviations}
\begin{enumerate}
-\item \emph{Strict mode} -- JFFS3 writes and always checks node's
-checksums. For example, it makes sense to use this checksum mode for sensitive files
-like system libraries or if for different reasons if it is needed to
-detect errors as early as possible.
-\item \emph{Relaxed mode} -- JFFS3 writes, but does not check
-checsums when nodes are being read. It makes sense to use this mode on
-very reliable flashes like NOR.
+\item \emph{BB} - Bad Block
+\item \emph{CRC} - Cyclic Redundancy Check
+\item \emph{JFFS2} - Journalling Flash File System version 2
+\item \emph{JFFS3} - Journalling Flash File System version 3
\end{enumerate}
-Note, if flash is additionally protected by ECC at lower (MTD
-[\ref{ref_MTD}]) layer (i.e. NAND, AG-AND or ECC'd NOR chips),
-JFFS3 checks checksums if
-ECC failure was detected even in relaxed checksum mode.
-
-The checksum mode may be setup on per-file basis using extended file
-attributes. The default checksum mode is configured at
-compilation time.
-
%
-% Unclean reboot errors detection
+% DEFINITIONS
%
-\subsection{Unclean reboot errors detection}
-\label{ref_sec_unclean_reboot}
-The primary mechanism of the unclean reboot detection is the absence of
-summary node. If an eblock contains summary, and the summary itself has
-no errors, the eblock does not contain partially written nodes.
+\section{Definitions}
-The corerectness of summary nodes may be checked by either checking its
-checksum or by checking its end magic bitmask (if the media corruption
-errors are not being interested).
+\begin{enumerate}
+\item \emph{Block, Sector} --
+the minimal flash erasable unit.
-If there is no summary node in an eblock, the last node in this eblock
-should be checkd (using checksum) since it is possible that it was
-not fully written.
+\item \emph{Bad block} -- unreliable flash block which must not be exploited.
+NAND and AND flash chips may be shipped with bad blocks. These blocks are marked
+bad and must not be never used or erased. The technology also implies
+that new bad blocks may appear during the flash's life-cycle. These blocks
+may be marked bad too.
-%
-% Behaviour in case of checksum errors
-%
-\subsection{Behaviour in case of checksum errors}
-The common JFFS2 behaviour if the media corruption has been detected,
-is marking the file system
-with a kind of "corruptred" flag and rejecting to
-perform any IO operations with this inode. But there should a
-possibility to clean this flag and to force JFFS3 to ignore the
-corrupted nodes.
+\item \emph{Node} --
+basic JFFS3 data structure. Anything JFFS3 stores on flash is
+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
+data. Node header contains internal information while node data contains some
+user-visible data like file's content or name.
+
+\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,
+length, etc of all the vblock's nodes.
+
+\item \emph{Vblock, virtual block} --
+JFFS3 may treat several blocks as one vblock of bigger size.
+Thus, the minimal erasable flash unit from the JFFS3's viewpoint
+is vblock which consists of one or more flash blocks.
-If the checsum error is due to unclean reboot, the partially written
-nodes are just ignored.
+\end{enumerate}
%
-% Marking blocks bad
+% REFERENCES
%
-\subsection{Marking blocks bad}
-In case of NAND or AG-AND flashes, flash blocks may become bad and may
-be marked bad. Bad blocks are not used anymore.
+\section{References}
-According to \ref{ref_ToshibaNAND} the general method of bad blocks
-detection is the errors when writing or erasing blocks.
+\begin{enumerate}
+\item \raggedright \label{ref_MTD}
+Memory Technology Device (MTD) Subsystem for Linux,\\
+\url{www.linux-mtd.infradead.org}.
-If the write error has been detected, JFFS3 moves all data from
-this eblock to another eblock. Then the bogus block is erased. If the
-erase error has been detected, block is marked bad.
+\item \raggedright \label{ref_JFFSdwmw2}
+JFFS : The Journalling Flash File System,\\
+\url{http://sources.redhat.com/jffs2/jffs2-html/}
-%
-% Checksum algorithm
-%
-\subsection{Checksum algorithm}
-The JFFS3 checkum algorism is the pending issue. There was long
-discussion how to calculate checksum. See MTD-mailing list archives:
-December\\
-(\url{http://lists.infradead.org/pipermail/linux-mtd/2004-December/011137.html})
-and January\\
-(\url{http://lists.infradead.org/pipermail/linux-mtd/2005-January/011390.html}).
+\item \raggedright \label{ref_NANDMTD}
+NAND Flash,\\
+\url{http://www.linux-mtd.infradead.org/tech/nand.html}.
-Special test was written to measure different checksum algoritm's
-performance. It is wanted to run this test on different platforms.
-Currently only x86 and ARM results are known.
+\item \raggedright \label{ref_ToshibaNAND}
+Toshiba NAND Flash Applications Design Guide,\\
+\url{www.semicon.toshiba.co.jp/eng/prd/memory/doc/pdf/nand\_applicationguide\_e.pdf}.
-The test and x86/ARM results may be found at \\
-\url{http://lists.infradead.org/pipermail/linux-mtd/2005-January/011403.html}.
+\item \raggedright \label{ref_SamsungOneNAND}
+Samsung OneNAND, might be found at\\
+\url{http://www.samsung.com}.
+
+\item \raggedright \label{ref_RenesasAND}
+Renesas Technology - AG-AND / superAND Flash Memory, might be found at\\
+\url{http://www.renesas.com}.
+
+\item \raggedright \label{ref_AtmelDataFlash}
+Atmel DataFlash,\\
+\url{http://www.atmel.com/products/DataFlash/.}
-The test is
-implemented as the kernel loadable module. If you have possibility to run it on your
-platform, please do it and provide results. MIPS, ARM and PPC platforms
-are of special interest. Any suggestions are welcomed.
+\item \raggedright \label{ref_GormanVM}
+Mel Gorman, Linux VM Documentation,\\
+\url{www.csn.ul.ie/~mel/projects/vm}.
-\subsubsection*{JFFS2 correspondence}
-JFFS2 uses the CRC32 algoritm with the start seed 0.
+\end{enumerate}
%
-% MEMORY CONSUMPTION
+% CREDITS
%
-\section{Memory consumption}
-\subsection{JFFS2 and memory consumption}
-JFFS2 has no any structure on flash, i.e., there are no
-specific addresses which one may access to get specific JFFS2 information.
-Unlike JFFS2 most file systems have the super block data structure, which
-may be found at the specified address and the information about the whole file
-system may be read from that super block. JFFS2 has no super block. The
-only it has is the set of nodes on it. Nodes may be placed to any offset within
-the flash device, so may have any position. JFFS2 just writes nodes
-sequentially.
+\section{Credits}
+David Woodhouse\\
+Joern Engel\\
+Thomas Gleixner\\
+Josh Boyer\\
+Ferenc Havasi\\
+Joakim Tjernlund\\
+Jared Hulbert.
-The above design assumes the following.
-\begin{itemize}
-\item When JFFS2 is being mounted, the flash media must be scanned since
-there is no super block. This is the reason why the JFFS2 mount process is slow.
-And, roughly speaking, the mount time grows lineary with the growing file
-system size.
-
-\item JFFS2 nodes have no determined position on the flash chip. They are moved by the
-Garbage Collector from time to time, so their positions are dynamically changed.
-\end{itemize}
-
-To handle this, JFFS2 keeps track of all nodes in memory.
-This means, that mrde data is on the JFFS2 file system, more RAM JFFS2 needs to
-keep track of these nodes. The memory occupied by these objects is called "in-core"
-memory.
-
-Thus, the JFFS2 in-core memory consumption is the linear
-function of the file system size.
-
-Additionally, it is worth mentioning here, that the iget() operation in JFFS2
-is the linear function of the number of nodes in the inode. The reason is
-similar to why the mount time has the linear dependency. This is why opening
-very big file or lookuping the directory with many files is very slow operation
-in JFFS2.
+\small{Note: feel free to remind us to include your name if it has been
+forgotten.}
%
% MISCELLANIOUS
%
-\section{Miscellanious}
-This subsection contains the gathered list of different ideas and thoughts,
-suggested by different people but have not yet highlited/used in this
-document. Many of some of them may be quite good.
+\section{Miscellaneous}
+This section contains the gathered list of different ideas and thoughts
+suggested by different people but have not yet highlighted/used in this
+document. Many of them may be quite useful.
\begin{enumerate}
-\item Have some global or per-inode flag telling that there was a CRC
+\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 Ask zlib not to generate adler32 checksum. JFFS3 write
-checksums itself.\\
-\url{http://lists.infradead.org/pipermail/linux-mtd/2004-December/011137.html}.
-
\item Make the compression selectable per-file (may be using xattr).\\
\url{http://lists.infradead.org/pipermail/linux-mtd/2005-January/011645.html}.
@@ -489,15 +296,15 @@
\url{http://lists.infradead.org/pipermail/linux-mtd/2005-January/011644.html}\\
\url{http://lists.infradead.org/pipermail/linux-mtd/2005-January/011556.html}
-\item Make compression selectable ber file.\\
+\item Make compression selectable per file.\\
\url{http://lists.infradead.org/pipermail/linux-mtd/2005-January/011641.html}
-\item Have the end majic bitmask on all note types in order to be able
+\item Have the end magic bitmask on all note types in order to be able
to quickly detect the partially written nodes.\\
\url{http://lists.infradead.org/pipermail/linux-mtd/2005-January/011529.html}.
\item Increase the maximum node size. We may keep several pages in one node.
-This leads to better compression and less memory consumption. Ise
+This leads to better compression and less memory consumption. Use
zisofs-like technique when reading the node with several pages of data
(compressed).\\
\url{http://lists.infradead.org/pipermail/linux-mtd/2005-January/011672.html}\\
@@ -506,31 +313,6 @@
\item Implement write-back cache in JFFS3.\\
\url{http://lists.infradead.org/pipermail/linux-mtd/2005-January/011672.html}\\
and following.
-
-\end{enumerate}
-
-%
-% REFERENCES
-%
-\section{References}
-
-\begin{enumerate}
-\item \raggedright \label{ref_MTD}
-Memory Technology Device (MTD) Subsystem for Linux,\\
-\url{www.linux-mtd.infradead.org}.
-
-\item \raggedright \label{ref_GormanVM}
-Mel Gorman, Linux VM Documentation,\\
-\url{www.csn.ul.ie/~mel/projects/vm}.
-
-\item \raggedright \label{ref_ToshibaNAND}
-Toshiba NAND Flash Applications Design Guide,\\
-\url{www.semicon.toshiba.co.jp/eng/prd/memory/doc/pdf/nand\_applicationguide\_e.pdf}.
-
-\item \raggedright \label{ref_JFFSdwmw2}
-JFFS : The Journalling Flash File System,\\
-\url{http://sources.redhat.com/jffs2/jffs2-html/}
-
\end{enumerate}
\end{document}
More information about the linux-mtd-cvs
mailing list