jffs2_scan_eraseblock() errors - truly harmless?

jffs2_scan_eraseblock() errors - truly harmless?

[Frederic Giasson]

Hi,

I got a problem similar to the one discussed in the thread
"jffs2_scan_eraseblock() - errors in July 2002".  It first happened when I
rebooted my machine (with the reboot command) right after I copied a file
into my JFFS2 partition, and then when I mount the file system I get error
messages like these:

jffs2_scan_eraseblock(): Node at 0x0009d3f0 {0x1985, 0xffff, 0x1985c002) has
invalid CRC 0x00001024 (calculated 0x7861f409)
jffs2_scan_inode_node(): Data CRC failed on node at 0x0009f45c: Read
0x3d13f217, calculated 0x96196114
jffs2_scan_inode_node(): Data CRC failed on node at 0x0038101c: Read
0x71f9e2ad, calculated 0x98bc2d06

In the discussion thread mentionned above, you said that this problem is
harmless.  If the node with bad CRC was written in part only by the garbage
collector which was potentially moving the original node when the reboot
occured, the original node is still there and  valid, so in that way this is
harmless.

But since the error message does apparently not disappear easily, what about
the space used by the node with the bad CRC?  I looked at the code and at
mount time it is added to the dirty space, but it is not marked as obsolete
on the medium...  thus the gc will not collect it.  In a system where power
fail would be frequent so this problem would have higher possibility to
occur, then a lot of flash space could be wasted. In that way, it is
harmless.

You also mentionned than in old JFFS2 code those nodes with bad CRC are
marked as obsolete when discovered at mount time, but where is this
happening?  I loooked at old code ( as per 2.4.19-pre7 ) and the
jffs2_scan_eraseblock() function does not seem to obsolete the nodes
obsolete itself. Where is this obsoleting done?

I am using CVS code as per July 3rd.  I know that more recent code should
not complain with such messages at mount time, but unless absolutely
necessary I'd rather not upgrade right now.  If I am right when I say that
the GC will not collect the bad CRC node, how could I patch the code
(without side effects!) to obsolete the bad crc nodes?

Thanks,

Frédéric Giasson

Re: jffs2_scan_eraseblock() errors - truly harmless?

[David Woodhouse]

fgiasson@mediatrix.com said:
> But since the error message does apparently not disappear easily, what
> about the space used by the node with the bad CRC?  I looked at the
> code and at mount time it is added to the dirty space, but it is not
> marked as obsolete on the medium...  thus the gc will not collect it.

The GC _will_ collect it. Marking stuff obsolete on the medium is just an 
optimisation to speed up the scan, what's important is whether we consider 
it obsolete in our in-memory records. Which we do -- when we happen to GC 
the block containing the node in question.

>  You also mentionned than in old JFFS2 code those nodes with bad CRC
> are marked as obsolete when discovered at mount time, but where is
> this happening?  I loooked at old code ( as per 2.4.19-pre7 ) and the
> jffs2_scan_eraseblock() function does not seem to obsolete the nodes
> obsolete itself. Where is this obsoleting done? 

Er, I can't see it. I could have sworn that we used to mark the offending
nodes obsolete on the medium when we saw the CRC fail, so we didn't check
the same CRC again and hence didn't whinge about it again. Then when the
accounting changed with the rotate_lists stuff I stopped it doing that
briefly, then changed it back again when I realised it was complaining about
the CRCs repeatedly. Maybe ask me again in the morning :)

> I am using CVS code as per July 3rd.  I know that more recent code
> should not complain with such messages at mount time, but unless
> absolutely necessary I'd rather not upgrade right now.  If I am right
> when I say that the GC will not collect the bad CRC node, how could I
> patch the code (without side effects!) to obsolete the bad crc nodes? 

It will GC them when it gets round to it. Leave it.

--
dwmw2