[PATCH] mtd: nand: write bad block marker even with BBT

[Shmulik Ladkani]

On Mon, 12 Dec 2011 13:53:08 -0800 Brian Norris <computersforpeace at gmail.com> wrote:
> On Mon, Dec 12, 2011 at 12:49 PM, Artem Bityutskiy <dedekind1 at gmail.com> wrote:
> > 2. Would the case of inconsistency between BBT and OOB markers be
> > possible to fix-up after the power cut?
> 
> Not trivially :) I suppose we could assume that any bad block markers
> in the OOB are in the BBT (when it exists) but not vice versa, then
> when we rebuild the BBT at boot time, we rescan the OOB only on the
> bad blocks, rewriting to OOB if necessary. Eventually, this kind of
> degrades to usefulness of the BBT though, if you're always checking
> back with the OOB markers.

What about the following scheme for 'nand_default_block_markbad' in case
NAND_BBT_WRITE_BBM is on:

1. Invalidate exising on-flash BBT
2. Update the BI marker on the OOB
3. Update the on-flash BBT

If a power cut occurs just before (1), then we failed to update either
BBT or OOB with the newly detected bad block. Can't do much about that.

If a power cut occurs between (1) and (2), then upon next boot the BBT
will be rebuilt by scanning the device.
Assuming all former bad blocks were indeed marked in their OOB (since
NAND_BBT_WRITE_BBM was on), then the scan would lead to a BBT identical
to the old BBT that was invalidated.
Again, the "new" bad block would not be marked - same case as if the
power cut occured before (1).

If a power cut occurs between (2) and (3), then upon next boot the BBT
will be rebuilt by scanning the device - this time the new BBT will
contain the newly detected bad block, since it was already OOB marked.

Invalidating the on-flash BBT might be implemented by erasing its block,
for example.

I guess this is a bigger change than the patch suggested, since
'nand_bbt.c' should expose interface for invalidating the BBT.

Also, need to examine if this scheme fits a scenario where there are
both main and mirror BBTs.