jffs2 scary messages

David Woodhouse dwmw2 at infradead.org
Tue Aug 7 05:53:29 EDT 2001

ken at magneticscrolls.com said:
>  jffs2_scan_empty(): Empty block at 0x00c8fffc ends at 0x00c90000 (with 0xe0021985)! Marking dirty
> jffs2_scan_empty(): Empty block at 0x00cafffc ends at 0x00cb0000 (with 0xe0021985)! Marking dirty

You probably didn't give mkfs.jffs2 the correct '-e' option to tell it the 
erase size. Harmless.

> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00d00070: 0x1a1a instead 

Looks like you're using the Compaq bootldr, which always used to write 
some crap at the end of a downloaded image if you didn't pad it to the end 
of a block with 0xFF. I think it should be fixed in later versions, or use 
the '-p' option to mkfs.jffs2 to pad the image to the next erase block

ken at magneticscrolls.com said:
>  I'm becoming a bit paranoid about JFFS2. I find that with only 16MB
> of flash getting to within a couple of hundred k of a full filesystem
> tends to result in an unrebootable system. Running 32MB seems much
> better.

What does 'unrebootable' mean?

> Another random question - does 'sync' do what might be expected or is
> it a no-op? 

Both. All operation on JFFS2 is synchronous anyway, so 'sync' is a no-op. 
But equally, you can be 100% sure that after a 'sync' everything is flushed 
to the flash - because it already was :)


More information about the linux-mtd mailing list