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
boundary.
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 :)
--
dwmw2
More information about the linux-mtd
mailing list