[PATCH v4 2/2] mtd: nand: write BBM to OOB even with flash-based BBT

[Shmulik Ladkani]

On Fri, 20 Jan 2012 20:38:04 -0800 Brian Norris <computersforpeace at gmail.com> wrote:
> The new flash-based BBT procedure for marking bad blocks:
>  (1) erase the affected block, to allow OOB marker to be written cleanly
>  (2) update in-memory BBT
>  (3) write bad block marker to OOB area of affected block
>  (4) update flash-based BBT
> Note that we retain the first error encountered in (3) or (4), finish the
> procedures, and dump the error in the end:
> 
> This should handle power cuts gracefully enough. (1) and (2) are mostly
> harmless (note that (1) will not erase an already-recognized bad block).
> The OOB and BBT may be "out of sync" if we experience power loss bewteen
> (3) and (4), but we can reasonably expect that on next boot, subsequent
> I/O operations will discover that the block should be marked bad again,
> thus re-syncing the OOB and BBT.
> 
> Note that this is a change from the previous default flash-based BBT
> behavior. If your system cannot support writing bad block markers to OOB,
> use the new NAND_BBT_NO_OOB_BBM option (in combination with
> NAND_BBT_USE_FLASH and NAND_BBT_NO_OOB).

Looks good.

I've came up with another idea - an addition to your patch which
improves BBM vs BBT out-of-sync handling in a rather simple,
non-intrusive way, adapting Artem's idea of lazy checking.

Users of the MTD interface use the 'mtd->block_isbad' method for
querying the badness of a block.

Current implementation ('nand_block_checkbad') queries the in-ram BBT
(using 'nand_isbad_bbt'), which was built by scanning the on-flash BBT
in the NAND_BBT_USE_FLASH case.

We could augment 'nand_block_checkbad' as follows:
- query the in-ram BBT (nand_isbad_bbt)
- if !NAND_BBT_USE_FLASH or (NAND_BBT_USE_FLASH && NAND_BBT_NO_OOB_BBM)
   single source of badness indicator. return the in-ram bbt value
- otherwise, also read from the OOB BBM using 'chip->block_bad'
- if no inconsistency, we're done
- inconsistency? synchronise:
   OOB BBM is marked? update flash BBT
   BBT marked? update OOB BBM // shouldn't happen, OOB was marked first

This way we keep them synced using lazy checking, relying on the fact
that MTD users use the 'block_isbad' interface for querying the badness
of a block.

The penatly is a 'chip->block_bad' (OOB read) invocation per
'block_isbad' call.

Alternatively, we can do it only once, within 'nand_isbad_bbt', if we
have an additional bit per eraseblock in the in-ram BBT, as Artem
suggested.

I assume this additional feature isn't a must, but OTOH it doesn't look
like a drastic change.

Regards
Shmulik