[PATCH v3 0/6] NAND BBM + BBT updates

[Angus CLARK]

On 01/11/2012 10:28 PM, Artem Bityutskiy wrote:
> In my view, OOB BB markers is the primary, reliable, and simple
> mechanism. And BBT is just an additional optimization to speed up system
> startup.

This seems to be contrary to the advice given by the various NAND manufacturers
(with a quite unusual show of consensus!)  Once a block has been deemed to have
gone bad, one cannot rely on *any* operations being successful, and that
includes writing a bad block marker to the OOB area.  The recommended approach
has for some time been to use a Flash-resident bad block table, with an initial
scan for the manufacturer-programmed bad-block markers.

(Indeed, this issue was raised recently in a meeting with one of the major NAND
manufacturers, and the design enginner was horrified at the thought of relying
on the OOB for tracking worn blocks.)

The use of OOB BB markers certainly has some benefits (as already mentioned in
previous posts), and I like the idea of being able to use OOB markers in
conjunction with BBTs.  However, IMHO, I believe the BBT should be regarded as
the primary source of information, especially when considering inconsistencies
between the OOB markers and the BBTs.

> 1. When we get erase error. Well, if SW erases a block, it does not care
> of the contents. This means that if after the reboot SW will re-try
> erasing it. And if the block is bad, and previously the erasure failed,
> it will fail again, and SW will mark it as bad again.
> 

This raises another point.  It is entirely possible that an erase operation will
succeed on a block where it previously failed.  However, that does not mean to
say the block has now become good.  On first erase failure, the block should be
considered bad and steps taken to ensure the block is not used.

In other words, we cannot rely on erase failures as a way of recovering bad
block status, although I accept in some circumstances, it is probably the best
we can do!

Cheers,

Angus