NAND flash and JFFS(2)

[David Woodhouse]

On Tue, 5 Feb 2002, Veli-Pekka Ylönen wrote:

> I read TODO file in JFFS2 sources and found this:
> 
> - NAND flash support:
>     - Fix locking in jffs2_garbage_collect_deletion_dirent().
>     - Move CLEANMARKER into the 'spare' area.
>     - Write batching - build up a NAND-page worth of data and write out all in
> 	one go, using the hardware ECC or block-based software ECC. This gives us
> 	some interesting problems, but it's not that bad:
> 	- When we go to erase a block from which we've been garbage-collecting,
> 	  we have to make sure that the nodes in it _really_ are obsolete, and
> 	  the new node which finally obsoletes the block we want to erase isn't
> 	  still waiting in the write-buffer. We can do this by sticking such
> 	  blocks not on the erase_pending_list, but on a new erase_pending_wbuf
> 	  list, and then moving them to the erase_pending_list when the buffer is
> 	  flushed.
> 	- fsync() becomes a non-NOP.
> 	- Deal with write errors. Data don't get lost - we just have to write
> 	  the affected node(s) out again somewhere else.
> 
> Is somebody already working on this?

Vaguely. 

I've had a go at some of these - I got terminally bored on the plane to
linux.conf.au so 've just checked in code to the experimental
jffs2-nand-branch in CVS which does the CLEANMARKER bit, although we
probably want to check where we should put the cleanmarker in NAND flash
to avoid all the hardware ECC arrangments. I know this one is OK with the
DiskOnChip but don't remember offhand where SmartMedia puts its ECC data.

I've done some of the write batching too - we have code to set up a write
buffer, flush it when it's full, etc., do the erase_pending_wbuf_list
thing, etc.

It doesn't yet deal nicely with write errors, although we know how, and I
haven't implemented fsync(). Neither have I tested that any of it does
anything more than actually compile - it's just there as more verbose
outline of what I think needs doing than what I put in the TODO list.

The whole thing wants a locking audit too. It's not just the 
gc_deletion_dirent code, although that is known broken and a little hard 
to fix - we need to drop the lock for reading the block in question, but 
then when we lock again we have to start again from the beginning of the 
list - and how do we know where we got to, given that the block we just 
looked at, the block before it and the block after it could all have gone 
from the list?

Perhaps we want to make the erase_completion_lock into a semaphore. I'm 
sure we could persuade the MTD maintainer to retrospectively declare that 
all erase callbacks must happen in process context. In fact, the freeing 
of the node refs in erased blocks already happens from process context - 
we could possibly just invent a new semaphore which protects us from that.

> I read also in the archive that JFFS should support NAND. Is this true?
>
> I have made the raw NAND interface work but JFFS and JFFS2 doesn't
> do the batching and tries to write multiple times to same
> page.

JFFS ought to be OK on chips that can take ten write cycles per 512-byte 
page, because it uses writev to ensure that nodes are written in one go, 
and no node will be less than 52 bytes. 

On NAND flash chips which can do fewer than ten writes per page, JFFS 
probably won't work either.

-- 
dwmw2