JFFS2 on NAND flash/DiskOnChip.

Quite a few people have asked about JFFS2 on NAND flash recently.

At least one has been serious enough to have approached a local contractor and offered money for it - but that company didn't want to put up _all_ the money to get it done.

That contractor didn't want to abuse the mailing lists by trolling for business, but I _want_ him to get this contract and get it working - largely because I'm tired of say 'no, sorry we can't do that yet'.

So I'd like to know if anyone else would be interested in contributing to the same contract. Otherwise, it's likely to stay on my TODO list until Red Hat gets a contract to do it, or unless the contractor in question manages to do it for next-to-no money.

Please contact me in private if you're like to pursue this.

(Sorry for the list abuse.)

--
dwmw2

Smile !

I tried jffs2 on a NAND flash. Tracking down one ugly bug in fs/jffs2/write.c i got it basicly working !
Thanks to all of you, who did his job on that jffs2/nand stuff obviously without having access to a NAND device.

Bug description
If you write a file a empty dnode is created first. jffs2_do_create calls

	jfss2_write_dnode(c, f, ri, NULL, 0, phys_ofs, &writtenlen);

jfss2_write_dnode puts NULL & 0 , which is data and datalen into

	vecs[1].iov_base = (unsigned char *)data;
	vecs[1].iov_len = datalen;
and then calls 
	ret = jffs2_flash_writev(c, vecs, 2, flash_ofs, &retlen); 

2 is the number of vecs assigned to this job.

jffs2_flash_writev calls mtd->writev, if available else it calls mtd_fake_writev. The nand driver supports writev and does not check if the vecs[1] entry is empty. mtd_fake_writev takes care of this.
I suggest to do the check in jffs_write_dnode (where the wrong count comes from), although i will include a check in nand.c.
This problem did not show up due to the fact, that obviously none of the FLASH drivers supports writev. (I could not find one in mtd)

Patch is committed to CVS

Thomas
__________________________________________________
Thomas Gleixner, autronix automation GmbH auf dem berg 3, d-88690 uhldingen-muehlhofen
fon: +49 7556 919891 , fax: +49 7556 919886
mail: [email protected], http://www.autronix.de

Be careful. You have nothing there to make sure that it doesn't violate the constraints on the number of write cycles per page. You have no ECC, you have no real chance of it working in the wild.

Also note that the locking in jffs2_garbage_collect_deletion_dirent() is broken. We need to lock the erase_completion_lock while we go through the list, and drop the lock when we read the nodes.

All the writev stuff was put there for the benefit of NAND flash - so yes, nobody's used it yet. This problem had come up recently in the eCos port, but the fix hadn't yet propagated to the main tree.

--
dwmw2

I know that and i was trying to put a workaround for the write cycle problem into the nand driver. I think thats the correct location for this. Are there other chips dealing with the same problem or is it related to NAND only ? My current solutiun would be:
In nand.c the write functions checks the write attempts to a page. If there were three writes already to this page, the function reads back the block data, erases the block and writes the block data back to the chip.

Is this also a problem for jffs1 ? I run jffs1 for a couple of weeks on my board and had not one problem at all.

I'm not deep enough inside this to see the neccecary change. Could you please explain more detailed ?

No problem it took only some time to understand what happens there.

Thomas
__________________________________________________
Thomas Gleixner, autronix automation GmbH auf dem berg 3, d-88690 uhldingen-muehlhofen
fon: +49 7556 919891 , fax: +49 7556 919886
mail: [email protected], http://www.autronix.de

Stupid question ! It happens on jffs1 too. I built in a check for consecutive page writes and it happens sometimes. The maximum number of consecutive writes to a page was 4. But there was never a loss of data or something like this. Strange !

Works, but in case of powerdown between erase and writeback the filesystem is left corrupted.
There would be a easy solution for this inside the nand-driver. The nand driver reserves some blocks at the end of the device and uses them to store the block data. If the data are succesfully stored the concerned block can be erased safely and data put back into this. In case of reset between erase and writeback the data is safe. When bringing up the NAND-driver we could check, if there is a safed block in the buffer and bring it back to the original location before mounting. This would not bring all this NAND problems into jffs and jffs2.

Thomas
_________________________________________________
Thomas Gleixner, autronix automation GmbH auf dem berg 3, d-88690 uhldingen-muehlhofen
fon: +49 7556 919891 , fax: +49 7556 919886
mail: [email protected], http://www.autronix.de

( moved to jffs-dev list )

Some new ST chips have similar problems, I think. You can only write once to any given 8-byte region before erasing it.

You can't do it like that. What if you lose power while the block is erased, but before you have written the data back again? You lose all the information from the remainder of that erase block.

See http://mhonarc.axis.se/jffs-dev/msg01140.html

I think you get away with it on JFFS1. You don't have nodes small enough that you'll fit ten of them in a page, and you can go for a couple of weeks without the lack of ECC biting you.

On completion of a block erase, we walk through all the node lists, and we remove and free all nodes in the block which has just been erased. Anything which walks the node lists (as this function does) must hold the erase_completion_lock, so that the erase can't happen simultaneously.

So we must hold the erase_completion_lock while walking the lists, and because it's a spinlock we must unlock it before calling the flash read function. Then when we get it again the node we were looking at and the next node in the list may both have gone and been freed - we have to start again from the beginning.

--
dwmw2