JFFS2 errors on ppc-4xx with CFI NOR flash

[Ryan Thompson]

Thank you Massimo. I received your private email and will respond from
my company address with the info you've asked for.

- R

On Mon, Mar 8, 2010 at 5:24 AM, massimo cirillo <maxcir at gmail.com> wrote:
> 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/
>>
>>
>