I understand that if a block erase fails it can be marked as bad. If a page write fails immediately it can also be marked bad. I have a board that shows "read disturb" and/or "program disturb" errors after very few reads or writes, should UBI mark the block as bad?

Should erasing a block always reset the disturb level? If not, as in my case, what could be wrong? Could the charge pump within the flash chip be damaged? If so how could this have happened?

I have written a Linux driver to test the flash at the MTD level and after a "read disturb" has flipped bits in an erased page, subsequent reads of that page may be OK (no ECC errors). How can this happen? Is this expected?


1 Answer 1


Here is a useful link when using UBI:FS, but as it's the official documentation, you've probably already read it.

The first thing to know is that UBI behavior depends on MTD, which rely on your NAND controller driver. I will try to answer using NAND flash requirements, MTD ones and UBI ones.

According to NAND datasheets, (here, I have a Toshiba SLC NAND, 8-bits ECC, but it's a common recommendation amongst Micron, Hynix, Samsung), if a block erase fails, the block should be marked as bad. If a page write fails, the block should be marked as bad. The definition of "fails" evolved with technology. With 4 and 8 bits ECC Flashs, it is common to have some bits sticked to 0 or 1. A write is commonly regarded as OK if, when reading the page just after the write, there is strictly less bitflips than acceptable. You may choose also to reduce your acceptance threshold to improve robustness, but being to restrictive restricts the number of blocks you use, and reduce the life length of your part, as wear is leveled on less blocks, and blocks are marked bad sooner.

Read disturb may also happen later. NAND flashs are made with floating gate transistors, which may discharge over time, or due to the activity on the current page, or even the other pages of the block. This is a known behavior of the NAND flash, and this is why flash filesystems should read every data often: to detect when some pages reach the maximum number of correctable bitflips. In such case, the page should be relocated, but the block isn't bad.

You may also get traces if ECC correction happen, even if this doesn't trigger the relocation. It depends on your driver.

And, at last, an erase page may contain some bits sticked to 0. In that case, ECC correction on read fails, while the page is OK. To avoid this issue, there is often a "page written" market added in the spare area, bigger than 2 times the maximum bitflips number for the NAND, which allow to ignore ECC errors on unwritten pages. In this case, your driver may fix bitflips before returning the page to the upper layers, resulting in a "read disturb" notice and no error reports to the upper layer.

As you may see, the behavior mainly depends on your NAND controller driver. Maybe your driver is open-source ? This would allow to get the actual behavior.

  • \$\begingroup\$ The driver is open source (codeaurora.org/cgit/quic/femto/kernel/msm/tree/drivers/mtd/…). Your comments have re-enforced my understand, so thanks for that. \$\endgroup\$
    – sbaconbits
    Jul 7, 2014 at 11:05
  • \$\begingroup\$ My main question is really, why isn't the "disturb level" getting fully reset upon an erase? \$\endgroup\$
    – sbaconbits
    Jul 7, 2014 at 11:06
  • \$\begingroup\$ One thing I've often thought would be very helpful when I've worked with NAND flash (though none of the NAND-flash systems I've used have included it) would be a smaller memory with more flexible structure and greater reliability. Even having one byte per page which was guaranteed reliable and which permitted bits to be programmed individually would be helpful. It would seem like the silicon cost should be pretty reasonable (in an MLC flash, even if each bit required three separate storage elements for redundancy, versus using two 16-level elements for the byte... \$\endgroup\$
    – supercat
    Aug 3, 2014 at 16:24
  • \$\begingroup\$ ...that would represent a tiny fraction of the overall memory array. I would guess there's a chicken-and-egg problem (authors won't code for features whose existence can't generally be relied upon, and manufacturers don't want to add features code's never going to use) but the consequences seem unfortunate. If a page gets relocated because of read errors, it would seem desirable to be able to invalidate the page in a fashion which doesn't depend upon the validity of the bits which are already known to be unreliable. \$\endgroup\$
    – supercat
    Aug 3, 2014 at 16:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.