[U-Boot-Users] Re: jffs2

Joakim Tjernlund joakim.tjernlund at lumentis.se
Wed Mar 5 18:13:28 CET 2003


> Hi,
> 
> > A colleague has tracked the problem down to the length determination
> > code in jffs2_1pass_read_inode. The code (protected by a brown paper bag
> > statement ;) claims that the file end is determined by an identical
> > isize in 2 following flash inodes which seems to be wrong. He has
> > implemented another variant, based on a sorted list, which seems to be
> > better but takes up to 20 seconds for the first scan. This is
> > unacceptably long but more correct... 
> 
> Let me clarify this a bit. To be correct, I worked on 3 different bugs.
> 
> The 1st one actually fixes only the length calculation.
> The right thing to do is to find the "newest" data node (the one with the highest version number) belonging to the inode. 
> That one has the correct length.
> 
> After that, I had crashes with a large JFFS2 fs. The reason is the memory management in add_node, which has massive bugs.
> 
> Then I recognized that, in case of an unfinished garbage collection, there might be duplicate fragments of the file around.
> For each file position, only the fragment with the highest version is valid, the other ones might contain old data.
> To handle that, I sorted the fragments in ascending order while scanning the fragments.
> Since the copy loop in read_inode copies while running over the fragment list, the newest copy will be copied last, hence 
> everything is ok.
> 
> This sorting takes a rather long time. Actually, for about 3000+ fragments, an average of 600 loop runs per fragment :-(
> 
> Any ideas are very welcome! Patches for interested parties available upon request.

In 2.4 JFFS2 all nodes were CRC32 check in the mount process which took a rather
long time. I then optimized the CRC32 function and added point() support(use a pointer 
to flash instead of reading the data into a buffer) and thing got better. Then
David Woodhouse impl. a "delayed crc32 check" procedure and now the mount process
is really fast!

So my advice is to check how it's done in current MTD CVS and rewrite the
jffs2 loader. 

 Jocke





More information about the U-Boot mailing list