JFFS2 access time

JFFS2 access time

[DMcLeod]

Hi all,

We are using uClinux git 2.6.23. We have 4 2.5MB files sitting in a 
directory on a ~40MB jffs2 partition (on NOR flash). The very first time 
we do an 'ls' in that directory, the response takes literally minutes. 
After the initial delay, any accesses to those files are very 
quick.,,Originally, we started off with the Microtronix 1.4 kernel and 
it did not have this problem. The pre-git version of uClinux-dist had 
this problem but not as severe - it was more like 40 seconds to list the 
contents of that directory.


Thanks in advance,

Re: JFFS2 access time

[Josh Boyer]

On Wed, 16 Jan 2008 08:57:50 -0500
DMcLeod <dmcleod@bittware.com> wrote:

> Hi all,
> 
> We are using uClinux git 2.6.23. We have 4 2.5MB files sitting in a 
> directory on a ~40MB jffs2 partition (on NOR flash). The very first time 
> we do an 'ls' in that directory, the response takes literally minutes. 
> After the initial delay, any accesses to those files are very 
> quick.,,

That is normal for large files.  JFFS2 has do the CRC checking on all
the nodes for those large files.  That is a lot of nodes to check.  You
might want to look into using the eraseblock summary feature.

> Originally, we started off with the Microtronix 1.4 kernel and 
> it did not have this problem. The pre-git version of uClinux-dist had 
> this problem but not as severe - it was more like 40 seconds to list the 
> contents of that directory.

I have no idea what those two kernels are, but older JFFS2 used to do
all the CRC checking at mount time.  So mount would be slow and runtime
access would be relatively quick.

josh

Re: JFFS2 access time

[Ricard Wanderlof]

On Wed, 16 Jan 2008, DMcLeod wrote:

> Hi all,
>
> We are using uClinux git 2.6.23. We have 4 2.5MB files sitting in a
> directory on a ~40MB jffs2 partition (on NOR flash). The very first time
> we do an 'ls' in that directory, the response takes literally minutes.
> After the initial delay, any accesses to those files are very

By "the first time" to you mean the first time you boot the board at all, 
or the first time after each boot?

If you download a 10 MB JFFS2 image into a 40 MB partition, then JFFS2 
will upon mounting erase each flash sector in the unused 30 MB area and 
write cleanmarkers to it. This more or less blocks accesses to the flash 
during this time. However, this only occurs the first time the system is 
booted, after that, the partition is completely "JFFS2-formatted" and 
there shouldn't be any further delays.

/Ricard

Re: JFFS2 access time

[DMcLeod]

Josh Boyer wrote:
> On Wed, 16 Jan 2008 08:57:50 -0500
> DMcLeod <dmcleod@bittware.com> wrote:
>
>   
>> Hi all,
>>
>> We are using uClinux git 2.6.23. We have 4 2.5MB files sitting in a 
>> directory on a ~40MB jffs2 partition (on NOR flash). The very first time 
>> we do an 'ls' in that directory, the response takes literally minutes. 
>> After the initial delay, any accesses to those files are very 
>> quick.,,
>>     
>
> That is normal for large files.  JFFS2 has do the CRC checking on all
> the nodes for those large files.  That is a lot of nodes to check.  You
> might want to look into using the eraseblock summary feature.
>
>   
>> Originally, we started off with the Microtronix 1.4 kernel and 
>> it did not have this problem. The pre-git version of uClinux-dist had 
>> this problem but not as severe - it was more like 40 seconds to list the 
>> contents of that directory.
>>     
> I have no idea what those two kernels are, but older JFFS2 used to do
> all the CRC checking at mount time.  So mount would be slow and runtime
> access would be relatively quick.
>   
The Microtronix kernel is the kernel built by Altera's Quartus 6.1 
suite. By "pre-git" version, we just meant the packaged version from 
nioswiki, rather than getting it from the git server.

At any rate, it turns out that having the verbosity level set to 2 in 
the jffs2 section of menuconfig was our problem. The kernel was so 
dragged down by having to bombard /proc/kmsg with jffs2 printk's that it 
caused the huge delays we were seeing. We set verbosity back to 0 and 
all is well.

Thanks :-)
> josh
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
>