JFFS2 errors on ppc-4xx with CFI NOR flash

Joakim Tjernlund joakim.tjernlund at transmode.se
Sat Mar 6 10:22:01 EST 2010


>
> I also created the attached gnuplot graph showing the time taken to
> write 128KiB files versus the filesystem utilization. Note that the
> underlying partition size is 32128KiB.
>
> In case attachments don't work on linux-mtd, the graph is also hosted
> at http://ry.ca/clients/jffs2-128KiB.png

I am guessing the flash is busy erasing blocks so writes have to wait.
What if you pause your test when it starts to get slow for a few mins
and continue?

it is strange though that erase suspend isn't working for you. I have
no such problems and I use numonyx too, but not this exact part(don't have
part info available ATM)

>
> - R
>
> On Fri, Mar 5, 2010 at 11:36 AM, Ryan Thompson <i at ry.ca> wrote:
> > On Fri, Mar 5, 2010 at 3:56 AM, massimo cirillo <maxcir at gmail.com> wrote:
> >> I suppose you don't have CONFIG_MTD_XIP enabled.
> >> So in order to completely disable the suspend,
> >> please in chip_ready() function just after "case FL_ERASING:"
> >> (line 775) put the line "goto sleep;" and repeat your test.
> >> Let me know.
> >
> > By skipping the FL_ERASING case as you suggested, my test now
> > completes successfully without any INFO-or-higher kernel messages.
> >
> > However, it still takes a very long time. The initial files are
> > written out quickly (subjectively, performance seems similar to raw
> > mtd speed). However, after 50% or so, performance begins to degrade
> > dramatically. At 65%, a 256KiB file takes 11 sec to write. At 75%, 20
> > sec. 90%, 38 sec. 95%, 77 sec. 99%, 121 sec. The entire test took 28.4
> > minutes to go from 3%-100% on the ~32MiB partition.
> >
> > Performance seems somewhat consistent with my previous result:
> >
> >> 2010/3/4 Ryan Thompson <i at ry.ca>:
> >>> The errors continued until the filesystem actually reported 100% full
> >>> and my script terminated. The entire 3%-100% operation took about 21
> >>> minutes for <32MiB, and was definitely much slower towards the end
> >>> with all the errors.
> >
> > I've done a flash_eraseall -j followed by a reboot before each run.
> >
> > I also benchmarked the mtdblock performance without JFFS2 (also
> > getting input from urandom):
> >
> > # time dd if=/dev/urandom of=/dev/mtdblock16
> > dd: writing '/dev/mtdblock16': No space left on device
> > 64257+0 records in
> > 64256+0 records out
> > Command exited with non-zero status 1
> > real    5m 30.17s
> > user    0m 0.08s
> > sys     1m 2.66s
> > # perl -le 'printf("bytes written = 0x%08x\n", 64256 * 512);'
> > bytes written = 0x01f60000
> > # grep modules /proc/mtd
> > mtd16: 01f60000 00020000 "modules"
> >
> > - R
> >
> [attachment "jffs2-128KiB.png" deleted by Joakim Tjernlund/Transmode]
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/




More information about the linux-mtd mailing list