JFFS2 errors on ppc-4xx with CFI NOR flash

[massimo cirillo]

Ryan,
the reason of bad performances is the disabling of erase suspend on
every request (read and write), so when the garbage starts to free some
blocks with erase, this erase cannot be suspended.
If the performance is a problem for you, I should investigate about the
flash device you are using.
I'll write to you in private.

2010/3/6 Joakim Tjernlund <joakim.tjernlund at transmode.se>:
>
>>
>> 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/
>
>