Re: JFFS2: file contents in case of data CRC error

[Jamie Lokier <jamie@shareable.org>]

Korolev, Alexey wrote:
> So JFFS2 performed scan on read - found CRC error in node 
> -> JFFS2 marked node to be obsolete
> -> As result hole in the file has been formed. 
> -> You read 0x0 in the middle of the file. 
> 
> I think nobody considered such tests before. I am not sure if any file
> system may be reliable in such a case with temperature tests.
> 
> Unfortunately I have no idea how this issue could be solved :).

If the corruption makes it impossible to detect the node corresponding
to a block, then indeed how can it be solved?  If the bit flips happen
in the node header, not the data, there really is no way to know that
some data is lost from the right block.

I'm thinking the only way to detect this with high reliability is to
store summaries of the existence of blocks in another part of storage,
with checksums and serial numbers - like some of the latest disk
filesystems begin to.  Then missing nodes are detectable and can
translate to I/O errors in userspace.

The other way, is for apps themselves to store checksums of their
files.  I had to do this, because we were getting occasional zeroed
blocks from JFFS2, and that happened in the middle of executables, so
we had apps which would run and occasionally crash or go wrong because
part of their code contained zeroes.

To avoid random wrong behaviour, I checksummed executable programs
before running them.  It does seem it would be better if the
filesystem offered better integrity or error guarantees.

-- Jamie