Re: JFFS3 & performance

Jörn Engel
2005-01-13T15:41:03Z

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