Re: NAND flash misery

David Brown schreef:
Vladimir Vassilevsky wrote:

Guess how many bad blocks are typical for NAND flash of several GB capacity? As many as 2 percent! There could be the whole areas of hundreds of megabytes of the contiguous bad cells, as well as the random scatter.

It is possible to do the extensive read/write test to find the most of the unreliable blocks; but it takes many hours.

I didn't encounter this problem until we started to use the high capacity CF cards. The bad blocks were very rare for the cards of 1GB and below. Since the flash iself is hidden behind the IDE interface and a compatible file system, and the read/write performance is critical, it is generally impossible to apply an error correction scheme.

I was under impression that flash is more reliable then HDD; now I see that it is not so. Do you know how reliable are the IDE flash drives?


NAND flash always has defects in manufacturing - the devices are designed to cope with a certain level of faults to make manufacturing cheaper (the same applies to many other types of chips, and hard disks). Each sector in NAND has extra space for error correction and detection (IIRC, 512 byte sectors are actually 528 bytes in size). Bad blocks can be detected and marked during manufacture and testing, and blocks that go bad (due to wearing out) are detected in use and the data moved to different blocks.

The same thing is done with hard disks - the controller detects bad blocks, and re-maps them. There are a few differences, however - on hard disks, you get bad blocks in manufacturing but it is rare that a good block goes bad in use. With flash, the controller can almost always spot a bad block and recover the data (since it's normally a single bit failure, the ECC will fix it), while on a hard disk you lose data.

Modern hard disks rely (heavily) on ECC too, likewise a hard disk can spot blocks becoming bad before they become unrecoverable. In other words: the situation for traditional hard disks is not that different.
.

Relevant Pages

  • Re: NAND flash misery
    ... I didn't encounter this problem until we started to use the high capacity CF cards. ... Since the flash iself is hidden behind the IDE interface and a compatible file system, and the read/write performance is critical, it is generally impossible to apply an error correction scheme. ... The same thing is done with hard disks - the controller detects bad blocks, ... CF cards and other earlier flash devices are not that great at wear levelling and bad block handling. ...
    (comp.arch.embedded)
  • Re: NAND flash misery
    ... A HDD has one big problem: the lifetime tends to go to the end when it ... a flash card is easy to swap. ... 256 GB and bigger flash disks, even high quality hard disks are no ...
    (comp.arch.embedded)
  • Re: NAND flash misery
    ... a flash card is easy to swap. ... wear, the longer the lifetime, and the more you read rather than write, ... is really no point to bother about the wear leveling. ... 256 GB and bigger flash disks, even high quality hard disks are no ...
    (comp.arch.embedded)
  • Re: NAND flash misery
    ... Do you know how reliable are the IDE flash drives? ... HDDs wear out through use. ... For common desktop usage, a 32 GB flash disk will probably far outlast a typical hard disk - with 256 GB and bigger flash disks, even high quality hard disks are no longer competitive on reliability and lifetime for real applications. ...
    (comp.arch.embedded)
  • Re: NAND flash misery
    ... capacity CF cards. ... I was under impression that flash is more reliable then HDD; ... Each sector in NAND has extra space for error correction and detection ... It is even possible that the controller will continue using a block with bad bits, and will not disable the block until a certain number of bad bits have been found. ...
    (comp.arch.embedded)