JFFS2 is broken

[Vipin Malik]

At 01:57 PM 8/14/2001 -0400, Frederic Giasson wrote:
>My other program running at the same time is my testcase which fills JFFS2
>to 80% with various files, deletes them and continue to do on.

Be careful, in my tests, the worst case blocking times came when the flash 
was >90+%
full. You may want to increase the full % on your flash full program and 
retest.

As a matter of fact, how I tested was: I ran JitterTest itself and asked it 
to put its "fill file"
(not the log file- which i redirected to /dev/console) on my JFFS2 
partition. Then I let JitterTest fillup the entire flash partition and
measured the worst case jitter in this case.

This way you can measure the jitter time for a task writing to JFFS2 itself.

I also ran another test where in addition to the above, I also ran another 
version of JitterTest
(this time as a POSIX RT task) and did not make it interact with JFFS2 at 
all. The worst case
jitter of this guy told me the worst case jitter to expect in a task NOT 
interacting with JFFS2
even while there was another task filling up the JFFS2 partition in the 
background. The results I got
for this test were ~50ms.


>There is something else that I did and maybe you did'nt.  In my chip driver,
>I put a "if( current->need_resched ) schedule();" in these fonctions:
>atmel_0001_write(), atmel_0001_read() and atmel_0001_erase_varsize(), which
>are the functions called by mtdblock driver through the mtd_info structure.
>I put schedule()'s because I though that if an application request a write
>of 1MB to JFFS2, atmel_0001_write() would not return until that 1MB of data
>was compressed and written to JFFS2.  Same thing for read and writes.

Interesting point. Are your flash chips in my MTD flash database on 
www.embeddedlinuxworks.com?

Vipin