[RFC] slight UBI scan time improvement

[Nancy]

On 4/23/08, Artem Bityutskiy <dedekind at infradead.org> wrote:
> On Wed, 2008-04-23 at 16:01 +0800, Nancy wrote:
> >     Yes, the issue is go away by properly use MLC nand.
> >     But the write fail issue in UBI still exist! Suppose you are
> > properly used your Nand, when it return write fail, but can erase
> > successfully, UBI still group this block in good block heap. That is
> > wrong and dangerous.
>
> The driver may return I/O errors for many reasons, including bugs in the
> driver. Or this may be an dumb user who screwed up his flash. It might
> be something else. We do not wand to mark the eraseblock bad when it is
> _not_ bad.
>
> And it's not just erase successfully. We torture the eraseblock. We
> erase it, read it back, check it has all 0xFFs, then write 0xA5 pattern,
> read it back, check, erase again, read back, check, write 0x5A pattern,
> read back, check, erase, read back, check, write 0x00 pattern, read
> back, check, erase, read back check. Enough? If it is not enough, feel
> free to send a patch for better torturing.
>
> Please, refer the torture_peb() function for more details.
>
> So, we do not mark eraseblock as bad if it passed the torture test.
> Note, a bit-flip during torture test is enough to mark the eraseblock
> bad as well.
>
> In your particular case, you would have _all_ eraseblocks marked as bad
> if UBI did what you want.

Torure is enough : )
Will you please explain why pattern 0x00 is not enough, it still need
0xA5 and 0x5A. What these information come from? Thanks in advance.



-- 
Best wishes,
Nancy