[RFC] slight UBI scan time improvement

Artem Bityutskiy dedekind at infradead.org
Wed Apr 23 04:16:11 EDT 2008


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.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)




More information about the linux-mtd mailing list