Charles Manning wrote:
>YAFFS is being more cautious than that, which means that in theory YAFFS will
>lose blocks faster than they recommend. However from accelerated lifetime
>testing I've done, I have not seen this to be a practical problem since ECC
>errors are so rare once the problematic blocks have been removed.
>
>It also means that in theory YAFFS is likely to be more secure than something
>designed the way they recommend. I would be concerned that by the time you
>start getting programming errors you might be exposing yourself to data loss.
>
>Most of the ECC handling etc for NAND was designed in the old days (256-byte
>pages etc) when NAND was quite flaky and 1-bit errors were relatively common.
>These days NAND is far better and far less likely to give ECC errors except
>on a few "soft" blocks.
>
>It would be quite simple to change the retirement policy, but I'd like to see
>evidence that it is safe to do so first.
>
>
I don't know if "soft errors" are frequent on modern Nand flash (where
soft errors are defined on page 19). However if you decide to change
the retirement policy I will suggest this one (it should be safe too):
In case of ECC error fixed during read, erase the block and write it
again with
the same data and read verification, if the ECC still fails retire the
block.
That's because Toshiba document says about soft errors: "This condition
is cleared
by a block erase".
What do you think about it?
Another question:
Does YAFFS always performs its own write verification by reading back
the data?
Or relies on MTD write verification if enabled?
Thank you for the clarification,
Claudio Lanconelli
(text/plain)