mtd/html/tech faq.html,1.4,1.5

[jwboyer at infradead.org]

Update of /home/cvs/mtd/html/tech
In directory phoenix.infradead.org:/tmp/cvs-serv27143/html/tech

Modified Files:
	faq.html 
Log Message:
Add JFFS2 bad block section to FAQ


Index: faq.html
===================================================================
RCS file: /home/cvs/mtd/html/tech/faq.html,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- faq.html	26 Feb 2005 20:37:18 -0000	1.4
+++ faq.html	9 Mar 2005 02:33:01 -0000	1.5
@@ -167,6 +167,24 @@
 For <b>NOR FLASH</b> there are no restrictions. For <b>NAND FLASH</b> please read the NAND FAQ section.</p>
 </p>
 
+<h4>How does JFFS2 handle a block going bad in NAND flash ?</h4>
+<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>
+
 <hr>
 <a href="../index.html">Back to MTD Homepage</a>.</p>
 <hr>