> normally with raw nand you use ecc, right? yes, reasonably priced ones have an internal ECC engine, very cheap ones don't. The Linux NAND framwork has softwa

> normally with raw nand you use ecc, right? yes, reasonably priced ones have an internal ECC engine, very cheap ones don't. The Linux NAND framwork has software ECC engines for those (see also: previous discussion on HN[1]). > was there any ecc happening in your tests? I deliberately turned it off. Linux has an ioctl for that. If the chip supports it, you can read/write without ECC or even directly into the OOB area where ECC data would normally be stored. The problem with the more expensive MLC NAND was that it had some smarts built in. It could discover overwrite attempts, as well as certain write patterns and apply a scrambling mask to the bits, so that the stored bits would (hopefully) not diffuse over to their neighbors. > if you started with a page with valid ecc data and then tried to bash an arbitrary payload 1 bit in it to 0, you'd have a real challenge updating the ecc data to be consistent with the updated payload If you are implementing a raw flash driver, there is a "nandbiterrs" test that does roughly what you describe: it bashes an increasing number of bit errors into a page and reads it back with ECC re-enabled, checking how many errors are successfully corrected during read, before the ECC engine gives up. [1] https://news.ycombinator.com/item?id=38361139 https://news.ycombinator.com/item?id=38361139