JFFS2 in NOR Flash leaves 4K all zero holes in files

[Yogesh Gupta]

Hi all,

I am using a ARM-based system, running kernel 3.6.11-rt35 on TI8148 Davinci processor, including a Intel type NOR-flash of 64MB in size which is integrated as a mtd block devices and JFFS2 file system is flashed on one of its mtd partition with no compression and erase block of 128Kb. We use this JFFS2 partition for keeping Software packages(Kernel and Rootfs) and Configuration data(XML files) and mount this partition at system bootup.

We have observed that sometimes system does not boot as uImage or rootfs.ext.gz.uboot CRC mismatch happened after abrupt power reboot. After connecting debugger and bringing up the system we found that uImage/rootfs files has exact 4K chunk of all zeroes at many locations.

I searched and read the archives and found that GC(Garbage Collector thread) first ZEROED the location and then erase it.
Firstly, it is correct behavior for NOR type flash and How comes this 4K holes if my erase block is 128Kb ? How to prevent the system from creating these 4K holes due to unplanned power boot?

Secondly I use sync() and fsync() after writing on flash then unmount and then planned power reboot. This behavior also leave 4K zero holes into system as sync() just only schedule the write buffer flushing on filesystem. So I think it does not guarantee the flash is fully written.
So is there any way I can guarantee the flash is written completely?

Lastly I think if we do not mount this partition at system boot then GC will not run and mount only when we need to access the flash and then unmount. In such scenario who will clean or erase the dirty nodes and how JFFS2 keep the flash life long lasting by evenly spreading of nodes.

Thanks in advance,
Yogesh Gupta

The information contained in this e-mail is private & confidential and may also be legally privileged. If you are not the intended recipient, please notify us, preferably by e-mail, and do not read, copy or disclose the contents of this message to anyone.