Re: gc problem?

Hi, David

damn fast response ;-) open source shows it's strenght!

> 0x000000a0 is the physical address of the offending datanode within the
> JFFS2 partition. 

Is this a byte address or a data node number (how big are the nodes?) or 
a flash sector number?

> We're trying to garbage-collect it; to write out a replacement so that
> it becomes obsolete and we can delete it. 
> 
> By following the lists of physical nodes, we determined it belonged to
> inode number 3. But when we fetched inode number three and walked its
> _logical_ lists, we didn't find anything referring to this physical
> node. Which sort of confuses us.

I understand.

Hmmm, maybe my partition is not well created (mkfs.jffs2 script from 
axis). After downloading the new empty image to the flash and rebooting, 
JFFS2 consumes a lot of processor power for some minutes, it seems to 
mark some free pages (lots of "starting erase of pending block..." 
messages).
During this process, the used space (from "df") increases up to 100% and 
then switches to 1% or so.

> Can you reproduce it?

Yes, and it on every test run it shows address 0x000000a0 and inode #3, 
even on another hardware!

> Take a copy of the offending partition first, and
> then grab the _whole_ log from before mounting the file system, while
> you reproduce it. 

I will try this tomorrow. Should I send the files to you?

Additional question: Is it possible to disable JFFS2 compression? In my 
application, size ist not the problem, but speed is.


Best regards,

-- 
Bernhard Roessmann
Don't Fear The Penguins!


To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to [email protected]