JFFS3 & performance

[Jörn Engel]

On Thu, 13 January 2005 15:22:38 +0000, Artem B. Bityuckiy wrote:
>
> Yes, I thought so either. But imagine due to unclean reboot the last CRC 
> was not written completely. this is the problem.

Agreed, it's hard to fully protect against such races.

Here is another design I'm not very happy about.  But it might work:

1) Checksum errors on the last node are silently ignored - most likely
   unclean reboot.

2) Last node per erase block is a special endmarker node, similar to
   cleanmarkers.

3) During unmount, an endmarker is written to the end of all
   partially-filled erase blocks.

Rule 1 makes sure we can somewhat distinguish between both problems
and don't report any false positives.  Rule 2 makes sure, we don't
miss real flash corruption on the last node, in case it occurs to the
last node of a full erase block.  Rule 3 closes the next small hole.

As long as GC doesn't obsolete/erase old node before the GC'd
something else is written behind the new node, this should be pretty
safe.  But it's horribly complicated.  Would be much nicer if the
checksum itself could distinguish between both cases.

Jörn

-- 
To recognize individual spam features you have to try to get into the
mind of the spammer, and frankly I want to spend as little time inside
the minds of spammers as possible.
-- Paul Graham