From fe95b3f8dfa3effeaa5a443004434cdeb8bc2bf9 Mon Sep 17 00:00:00 2001
From: Brian <brian@Brian-Ubuntu-Laptop.(none)>
Date: Sat, 6 Mar 2010 16:59:59 -0800
Subject: [PATCH] Spelling error of "write-through cache" in jffs2 FAQ
---
faq/jffs2.html | 526 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 526 insertions(+), 0 deletions(-)
create mode 100644 faq/jffs2.html
new file mode 100644
@@ -0,0 +1,526 @@
+
+
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+ <head>
+ <title>Memory Technology Device (MTD) Subsystem for Linux.</title>
+ <meta name="description" content="A generic subsystem for handling memory technology devices under Linux" />
+ <meta name="keywords" content="Disk-On-Chip, CompactFlash, Compact Flash, Disk On Chip, M-Systems, Linux, MTD, Flash, Memory Technology Device OneNAND" />
+ <link href="../styles/main.css" rel="styleSheet" type="text/css" />
+ </head>
+
+<body>
+ <div id="logo" align="right">
+ <img src="../images/logo3.png" alt="MTD Logo" />
+ </div>
+ <div id="main">
+
+
+
+
+
+
+ <div id="menu1">
+
+ <span class="nonsel">
+<a href="../index.html"><span>Home</span></a>
+</span>
+
+ <span class="sel">
+<a href="../faq/general.html"><span>FAQ</span></a>
+</span>
+
+ <span class="nonsel">
+<a href="../mail.html"><span>Mailing Lists / IRC</span></a>
+</span>
+
+ <span class="nonsel">
+<a href="../source.html"><span>Source</span></a>
+</span>
+
+ <span class="nonsel">
+<a href="../doc/general.html"><span>Documentation</span></a>
+</span>
+
+ <span class="nonsel">
+<a href="../misc/misc.html"><span>Misc</span></a>
+</span>
+
+ <span class="nonsel">
+<a href="../archive.html"><span>Archive</span></a>
+</span>
+
+ <span class="nonsel">
+<a href="../fellows.html"><span>Fellows</span></a>
+</span>
+
+ <p>Memory Technology Devices</p>
+
+ </div>
+
+
+ <div id="menu2">
+
+ <span class="nonsel">
+<a href="general.html"><span>General</span></a>
+</span>
+
+ <span class="nonsel">
+<a href="nand.html"><span>NAND</span></a>
+</span>
+
+ <span class="nonsel">
+<a href="onenand.html"><span>OneNAND</span></a>
+</span>
+
+ <span class="sel">
+<a href="jffs2.html"><span>JFFS2</span></a>
+</span>
+
+ <span class="nonsel">
+<a href="ubi.html"><span>UBI</span></a>
+</span>
+
+ <span class="nonsel">
+<a href="ubifs.html"><span>UBIFS</span></a>
+</span>
+
+ </div>
+
+
+ <div id="textbox">
+ <div id="text">
+ </div>
+
+
+
+<H2>Table of contents</H2>
+<OL>
+ <LI><A HREF="jffs2.html#L_magicnfound">I cannot mount JFFS2 and see "Magic bitmask 0x1985 not found" messages</A></LI>
+ <LI><A HREF="jffs2.html#L_hdd_jffs2">I am going to use JFFS2 on top of my hard drive, is it OK?</A></LI>
+ <LI><A HREF="jffs2.html#L_stick_jffs2">I am going to use JFFS2 on top of my USB stick/CF card/etc, is it OK?</A></LI>
+ <LI><A HREF="jffs2.html#L_messages">JFFS2 generates messages, is there a problem</A></LI>
+ <LI><A HREF="jffs2.html#L_loopback">I cannot loop mount a JFFS2 image</A></LI>
+ <LI><A HREF="jffs2.html#L_mtdblock">Do I need to use mtdblock to mount my JFFS2 filesystem?</A></LI>
+ <LI><A HREF="jffs2.html#L_rootfs">How do I get the 2.6 kernel to recognize JFFS2 as my rootfs?</A></LI>
+ <LI><A HREF="jffs2.html#L_writewell">How is ensured, that data is written to flash?</A></LI>
+ <LI><A HREF="jffs2.html#L_putimage">How to program an image to FLASH?</A></LI>
+ <LI><A HREF="jffs2.html#L_bbhandle">How does JFFS2 handle a block going bad in NAND flash?</A></LI>
+ <LI><A HREF="jffs2.html#L_clmarker">What is cleanmarker and what it is used for?</A></LI>
+ <LI><A HREF="jffs2.html#L_mkfs_jffs2_comp">How to compile mkfs.jffs2?</A></LI>
+</OL>
+
+
+
+<A NAME="L_magicnfound">
+<H2>I cannot mount JFFS2 and see "Magic bitmask 0x1985 not found" messages</H2>
+</A>
+
+<P>
+If you cannot mount your JFFS2 file system and you see many messages like
+</P>
+
+<CODE>
+jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000024: 0x2b10 instead
+<BR></BR>
+...
+<BR></BR>
+Further such events for this erase block will not be printed
+</CODE>
+
+<P>
+this means that the data on your flash device is not a valid JFFS2 file
+system. There is no single solution for this problem, but we will try to
+provide you some ideas how to fix this.
+</P>
+
+<P>
+The first question you should try to answer is "why the data on my flash
+device is incorrect so that JFFS2 rejects to deal with it?". There are may be a
+plenty of reasons, e.g.:
+</P>
+
+<OL>
+ <LI>you flash driver is severely buggy so it reads trash instead of valid data;</LI>
+ <LI>you flashed some trash instead of a valid JFFS2 image;</LI>
+ <LI>you did not manage to flash JFFS2 image correctly so that you ended up with
+ garbage on your flash, although the original image was perfectly fine;</LI>
+ <LI>you forgot to erase your flash before flashing it, etc.</LI>
+</OL>
+
+<P>
+Anyways, JFFS2 wouldn't complain if it was able to find correct data. As it
+does complain, there is something wrong with the data it reads.
+</P>
+
+<P>
+One common mistake is to use <CODE>/dev/mtdX</CODE> or
+<CODE>/dev/mtdblockX</CODE> devices to flash JFFS2 images on NAND flashes. E.g.
+</P>
+
+<CODE>cp jffs2_fs.img /dev/mtd2</CODE>
+
+<P>
+This is incorrect because when dealing with NAND flashes one has to skip bad
+eraseblocks and write only in NAND page size chunks. Please, use the
+<CODE>nandwrite</CODE> utility instead.
+</P>
+
+<P>
+Also please, do not forget to erase your flash before flashing the image. You
+may use the <CODE>flash_eraseall</CODE> utility for this. And it makes sense to
+make sure the erase functionality actually works my reading the erase MTD
+device back and checking that only 0xFF bytes were read.
+</P>
+
+<P>
+You may try to check if your flash driver works correctly and if you flashed
+the file system image correctly by means of reading the flash back after you
+have flashed your image, and compare the read image with the original one.
+Please, use the <CODE>nandread</CODE> utility to read from NAND flashes.
+</P>
+
+<P>
+You can also do the following experiment to make sure JFFS2 works well. Erase
+your MTD device and mount it to JFFS2. You will end up with an empty file
+system. Copy some files to the JFFS2 file system and unmount it. Then mount it
+again and see if it mounts without problems. If it does, this is most probably
+not a JFFS2 bug.
+</P>
+
+
+
+<A NAME="L_hdd_jffs2">
+<H2>I am going to use JFFS2 on top of my hard drive, is it OK?</H2>
+</A>
+
+<P>
+First off, JFFS2 was designed for MTD devices, not for block devices like hard
+drives. These are two very different types of devices. Please, read
+<A href="general.html#L_mtd_what">this</A>, and
+<A href="general.html#L_mtd_vs_hdd">this</A> and realize this difference.
+</P>
+
+<P>
+Now you understand that you are going to use JFFS2 with devices it was not
+designed for, is it OK? Obviously, it is generally not OK.
+</P>
+
+<P>
+It is possible to use JFFS2 with the <CODE>block2mtd</CODE> driver. The driver
+emulates an MTD device on top of a block device so that you may feed the
+emulated MTD device to JFFS2 and utilize the file system on top of it. But do
+not complain when you have noticed that the performance suffers.
+</P>
+
+<P>
+Owing to peculiarities of flash devices, JFFS2 is very different to
+conventional HDD-oriented file system. And one of its drawbacks is that mount
+time as well as memory consumption grow linearly with growing flash size. So
+beware you may end up with tremendous amount memory eaten and huge mount time if
+your block device is very large. Also, JFFS2 implements only write-through
+caching (while convectional FS-es have write-back) and does many thing which are
+not really needed in case of hard drives.
+</P>
+
+<P>
+So, beware of this and think twice. Also, nobody guarantees
+<CODE>block2mtd</CODE> is bug-free. It it mostly used for debugging purposes,
+when it is easier to utilize emulated mtd device on the host development
+machine rather then debug on the target board. But of course, if you tested it
+and everything is OK with you - go ahead.
+</P>
+
+
+
+<A NAME="L_stick_jffs2">
+<H2>I am going to use JFFS2 on top of my USB stick/CF card/etc, is it OK?</H2>
+</A>
+
+<P>
+USB sticks, CompactFlash cards and other removable flash media are <B>not</B> MTD
+devices. They are <B>block</B> devices. They do contain flash chip inside, but
+they also contain some translation layer above which emulates block device.
+This translation layer is implemented in hardware. So for outside world these
+devices look exactly as hard drives, not like MTD devices.
+</P>
+
+<P>
+Please, read <A href="jffs2.html#L_hdd_jffs2">this</A> FAQ entry about using
+JFFS2 on top of hard drives.
+</P>
+
+<P>
+So, the answer is probably yes, you technically can, but be sure you realize
+why you do this. In general it is bad idea. It is much better to use any
+conventional file system like ext2.
+</P>
+
+<P>
+Also note, these devices are "black boxes". The way they implement this
+flash-to-block device translation layer is not usually published. And in many
+cases the algorithms used at this layer are far from brilliant. For example,
+many USB sticks and other cards lose data in case of unclean reboots/power
+cuts. So, be very careful.
+</P>
+
+
+<A NAME="L_messages">
+<H2>JFFS2 generates messages, is there a problem?</H2>
+</A>
+
+<P>
+JFFS2 adopts the philosophy of keeping the user completely appraised of what is
+going on. This can catch out the unwary novice. The following messages can be
+moved to a higher log level once you are sure that they are benign.
+</P>
+
+<CODE>Empty flash at 0xXXXXXXXX ends at 0xXXXXXXXX</CODE>
+
+<P>
+This message is generated if a block of data is partially written. It is
+generally not a sign of any problem.
+</P>
+
+<CODE>
+Name CRC failed on node at 0x00b620c8: Read 0x640c8ca3, calculated 0x795111fe
+</CODE>
+
+<P>
+or similar message about CRC failures. If you have ever done unclean reboots -
+this is harmless. This just means that the unclean reboot happened (1) during
+data write or write buffer sync or (2) while GC was working or (3) while the
+write-buffer contained some data and was not yet synced before the unclean
+reboot happened. In them first and the third cases, you just lose the very
+last data you have written, in the second case you lose nothing. The wrong
+nodes will eventually be recycled by Garbage Collector and the massages will go
+(but they may leave quite long).
+</P>
+
+<P>
+But this also may mean that data on your flash was corrupted for sum reasons.
+Unfortunately JFFS2 cannot distinguish between node corruptions cause by
+unclean reboots and by real media corruptions. But the latter case is very
+rare.
+</P>
+
+<CODE>
+You cannot use older JFFS2 filesystems with newer kernels
+</CODE>
+
+<P>
+Please, update your MTD utilities and use newer mkfs.jffs2.
+</P>
+
+
+
+<A NAME="L_loopback">
+<H2>I cannot loop mount a JFFS2 image</H2>
+</A>
+
+<P>
+JFFS2 images can not be loop mounted. The loop device is essentially a driver
+which represents files as block devices. But JFFS2 works on top of MTD devices
+which are different. So an "mtdloop" device would be needed for this, but nobody
+implemented it yet.
+</P>
+
+<P>
+The only way to manipulate JFFS2 images is by copying them into a mtdram device
+and mounting the device with JFFS2.
+</P>
+
+<P>
+Also, if you are desperate, then fix jffs2_dump to recreate the filesystem from the
+image. It's not hard. All the basics are done already.
+</P>
+
+
+
+<A NAME="L_mtdblock">
+<H2>Do I need to use mtdblock to mount my JFFS2 filesystem?</H2>
+</A>
+
+<P>
+In general, mtdblock is not required to mount JFFS2 filesystems. One can use
+the MTD device name or minor number to specify the MTD device that contains the
+JFFS2 filesystem. For example, both:
+</P>
+
+<CODE>mount -t jffs2 mtd2 /foo</CODE>
+<BR></BR>
+<CODE>mount -t jffs2 mtd:name_of_device /foo</CODE>
+
+<P>
+should both work assuming the device specified actually contains a valid JFFS2
+filesystem.
+</P>
+
+<P>
+There are two cases where this does not work. The first is when JFFS2 is used
+as a root filesystem. For now, this requires the mtdblock device to be
+specified for <CODE>root=</CODE> on the kernel commandline. The second case is
+when the mount binary that is being used does not play nicely with the above
+format. The busybox version of mount is known to not work without the mtdblock
+device.
+</P>
+
+
+
+<A NAME="L_rootfs">
+<H2>How do I get the 2.6 kernel to recognize JFFS2 as my rootfs?</H2>
+</A>
+
+<P>
+With the 2.6 kernel, you will need to specify: <CODE>rootfstype=jffs2</CODE> on
+the kernel command line to use it as a root filesystem
+</P>
+
+
+
+<A NAME="L_writewell">
+<H2>How is ensured, that data is written to flash?</H2>
+</A>
+
+<P>On <B>NOR FLASH</B> each write goes directly into the FLASH.</P>
+
+<P>
+On <B>NAND FLASHM</B> and <B>NOR ECC FLASH</B> we have a write-buffer for
+writing only full pages to the chips. There could be a loss of data, when the
+write-buffer is not flushed before power down. There are some mechanisms to
+ensure, that the write-buffer is flushed. You can force the flush of the
+write-buffer by using <CODE>fsync()</CODE> or <CODE>sync()</CODE> in your
+application. JFFS2 has a timed flush of the write buffer, which
+forces the flush of the buffer to flash, if there are no writes
+to the filesystem for more than about 5 seconds. The time
+depends on the cycle-time of kupdated, which can be adjusted
+via <CODE>/proc/sys/vm/dirty_expire_centisecs</CODE>.
+</P>
+
+<P>When you unmount the filesystem the buffer is flushed too.</P>
+
+<P>
+If the partition is being used as a root filesystem, which obviously cannot be
+dismounted, the filesystem should be remounted read only on shutdown. In the
+case of JFFS2 this will cause the garbage collector to flush its write buffers.
+Failure to do this may cause the filesystem to generate warnings regarding bad
+CRC. These are partially collected garbage blocks which will be rescheduled
+for garbage collection some time later. This kind of behaviour may also be
+observed after a system crash.
+</P>
+
+
+
+<A NAME="L_putimage">
+<H2>How to program an image to FLASH?</H2>
+</A>
+
+<P>There are several possibilities to do so:</P>
+
+<DIV>
+<UL>
+<LI>From Linux</LI>
+<LI>From bootloader</LI>
+<LI>Via JTAG</LI>
+<LI>At production time</LI>
+</UL>
+</DIV>
+
+<P>
+For <B>NOR FLASH</B> there are no restrictions. For <B>NAND FLASH</B> please
+read the <A href="nand.html">NAND FAQ</A> section.
+</P>
+
+
+
+<A NAME="L_bbhandle">
+<H2>How does JFFS2 handle a block going bad in NAND flash?</H2>
+</A>
+
+<P>
+If an error occurs when writing to a page, JFFS2 will attempt recovery of the
+data. If the block contains nodes that have already been written to flash, the
+block is refiled onto the list of blocks that are bad but still in use (the
+bad_used_list). Then the write buffer itself is recovered. This takes into
+account any data that has been partially written to flash. Once the write
+buffer has been recovered, normal operation continues. Garbage collection is
+responsible for moving the valid nodes from the block that was refiled.
+</P>
+
+<P>
+Once garbage collection has written all of the valid nodes to a different
+eraseblock, the block is moved to the erase pending list. From there JFFS2
+will erase the eraseblock. If the erase failed, it is put on the erase pending
+list again for a retry. If the erase fails at the device level a total of
+three times, it is marked as bad in the OOB area and filed onto the
+bad_block_list. If the erase succeeds, a clean marker is written to the OOB
+area and the block is filed onto the free list. This is done because NAND
+flash can have non-permanent failures due to over-programing or write-disturb
+errors. A block erase clears these conditions.
+</P>
+
+
+
+<A NAME="L_clmarker">
+<H2>What is cleanmarker and what it is used for?</H2>
+</A>
+
+<P>
+Cleanmarker is a special JFFS2 node which is written to the beginning of a
+block just after the block has been erased. On NOR flashes it is a special
+small JFFS2 node at the beginning of the block. On NAND flashes it is placed to
+the spare area of the first page.
+</P>
+
+<P>
+The main reason why cleanmarkers are used is the need to be sure that the block
+erase operation was correctly completed. All 0xFF bytes in the block are not
+necessarily mean the block is ready to be utilized. For example, if an unclean
+reboot happened just at the end of the block erase cycle, the block might have
+unstable bits, which are read as "1" one time and might be read as "0" next
+time.
+</P>
+
+<P>
+When preparing a flash partition for JFFS2, it is recommended to put
+cleanmarkers to the erased blocks. This might be done my means of "-j" option
+of the "flash_eraseall" MTD utility. Otherwise, JFFS2 will re-erase the blocks
+which contain all 0xFF and have no cleanmarker. This is an unneeded wasting of
+time.
+</P>
+
+
+
+<A NAME="L_mkfs_jffs2_comp">
+<H2>How to compile mkfs.jffs2?</H2>
+</A>
+
+<p>The <code>mkfs.jffs2</code> utility requres the <code>ACL</code> and
+<code>zlib</code> libraries. In Fedora, please, install the
+<code>libacl-devel</code> and <code>zlib-devel</code> packages. In Debian,
+please, install the <code>libacl1-dev</code> and <code>zlib1g-dev</code>
+packages.</p>
+
+<p>Note, <a href="../faq/general.html#L_compile_mtd">this</a> section provides
+information about other dependencies in the <code>mtd-utils</code> tree.</p>
+
+ </div>
+ </div>
+ <div align="right">
+ <p>
+ Last updated: 12 Jan 2009, dedekind
+ <a href="http://validator.w3.org/check?uri=referer">
+ <img src="http://www.w3.org/Icons/valid-xhtml10"
+ alt="Valid XHTML 1.0!" height="31" width="88" />
+ </a>
+ <a href="http://jigsaw.w3.org/css-validator/">
+ <img style="border:0;width:88px;height:31px"
+ src="http://jigsaw.w3.org/css-validator/images/vcss"
+ alt="Valid CSS!" />
+ </a>
+ </p>
+ </div>
+ </body>
+</html>
--
1.6.3.3