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

[Angus CLARK]

On 01/18/2012 10:04 PM, Brian Norris wrote:
> On Tue, Jan 17, 2012 at 2:22 AM, Angus CLARK <angus.clark at st.com> wrote:
>> (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.)
> 
> That's interesting. I never had this impression, but perhaps the topic
> just never came up.
> 

Since it was first brought to our attention, we have sought clarification from a
number of sources.  The general consensus seems to be that if a block has gone
bad, then one cannot rely on any further operations succeeding, including
writing BB markers to the OOB area.  However, the extent to which this is a
problem in practice is less clear.  Many of us have been using OOB BB markers
for years without any issue, although perhaps we just haven't noticed!

> Anyway, the important question is: how does this impact the current
> solution I am developing? IMO, this seems primarily a matter of
> perspective, which would drive future development but does not
> fundamentally alter my proposed patch(es). 

Yes, I fully agree.  The patches add functionality that many of us would find
useful and should be regarded as a step in the right direction.

> Another note regarding the primary source: if the BBT is sufficiently
> corrupted (according to ECC), we fall back to the OOB markers. That
> doesn't make the flash-based BBT the 100% primary source, but I think
> it makes sense. This feature was pulled into the 3.2 release, BTW.

If the BBT becomes corrupted, then the best we can do is rely on OOB markers,
and your patch at least gives us a chance to recover information about blocks
that have gone bad through use.  However, it does concern me that the BBTs can
become corrupted in the first place.  Some systems have no other choice but to
rely on BBTs (e.g. no space or access to OOB).  For SLC NAND at least, the
pattern of use for the BBT blocks is well within the reliability/endurance
specifications.  Do you have some experience on BBTs becoming corrupted, other
than our own development practices, of course :-)

Cheers,

Angus