Re: NAND FLASH wear-out
Benjamin M. Schwartz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Mitch Bradley wrote: > >> The part is rated for 100,000 *erase* cycles per block. There are 64 >> independently-writable 2K pages per block. Writing doesn't count in the >> wear calculation - just erasing. >> > What does "rated" mean? Specifically, I imagine this means that X% of blocks > are expected to survive 100,000 erases, where X is at least 50. Even if X is > 99, there will still be some blocks that fail early, perhaps extremely early. > I > do not know what the failure curve looks like for erase blocks. > The data sheet says "DATA INTEGRITY: 100,000 Program/Erase cycles (with 1bit/512byte ECC), 10 years Data Retention". I don't know what that means. These parts are sold into the consumer electronics/consumer PC market. Low cost / short product life cycles reign supreme. We live in the modern throwaway world. Handwaving and marketing reign supreme. Not only that, but products are routinely developed by ripping off designs from other companies, cloning, rebranding, you name it. Data sheets are copied from other companies. > I am by no means an expert here, but from conversations with David Woodhouse, > I > have the following impression: > 1. We can expect each XO to lose a few erase blocks over the course of its > lifetime > 2. JFFS2 is specifically designed to handle erase-block failures without > losing > any data, so the only effect will be a minimal decline in the available disk > space. > That is correct, except that data can be lost if an erase block happens to die during a read cycle, losing enough bits that the ECC cannot correct it. >> The bottom line is that NAND wear-out is not likely to be an issue. >> JFFS2 does a good job of spreading out writes, and even if it only did a >> half-hearted job, that would probably be good enough. >> > > I agree. However, erase-block failure handling may be very important. > Indeed. I believe that David told me that the JFFS2 support for moving newly-found bad blocks to the bad block list is not fully implemented, so we may still have some work to do. > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.7 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFHfHnQUJT6e6HFtqQRAiwEAKCKQGB5vK7eQQR/Zmd4RDglmsxjPwCePox5 > BaqnTksnSlIZbPx1Ynq5hBk= > =dVXm > -END PGP SIGNATURE- > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: NAND FLASH wear-out
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mitch Bradley wrote: > The part is rated for 100,000 *erase* cycles per block. There are 64 > independently-writable 2K pages per block. Writing doesn't count in the > wear calculation - just erasing. What does "rated" mean? Specifically, I imagine this means that X% of blocks are expected to survive 100,000 erases, where X is at least 50. Even if X is 99, there will still be some blocks that fail early, perhaps extremely early. I do not know what the failure curve looks like for erase blocks. I am by no means an expert here, but from conversations with David Woodhouse, I have the following impression: 1. We can expect each XO to lose a few erase blocks over the course of its lifetime 2. JFFS2 is specifically designed to handle erase-block failures without losing any data, so the only effect will be a minimal decline in the available disk space. > The bottom line is that NAND wear-out is not likely to be an issue. > JFFS2 does a good job of spreading out writes, and even if it only did a > half-hearted job, that would probably be good enough. I agree. However, erase-block failure handling may be very important. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHfHnQUJT6e6HFtqQRAiwEAKCKQGB5vK7eQQR/Zmd4RDglmsxjPwCePox5 BaqnTksnSlIZbPx1Ynq5hBk= =dVXm -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
NAND FLASH wear-out
> >> I would hate to fill up my 1GB and use all my flash write cycles... >> The probability of wearing out NAND FLASH is much less than people seem to think. The part is rated for 100,000 *erase* cycles per block. There are 64 independently-writable 2K pages per block. Writing doesn't count in the wear calculation - just erasing. Suppose that you pick one block and use it exclusively. You write one page, then write another page, etc, and when you have filled all 64 pages, you erase the block and start over. What would it take to wear out that block over the 5-year design lifetime of the XO? 100,000 erases / 5 years / 365 days / 24 hours = 2.3 erases/hour. So you can erase the same block every 26 minutes, 24 hours a day, 365 days per year, for 5 years before the block is likely to wear out. But there are 64 pages per block, and you only have to erase after they are all written. 26 minutes * 60 secs/min / 64 pages = 24 seconds. So you have to write a page every 24 seconds to wear out that block. Obviously, if you have a very stupid application that is pounding on one block and writing/erasing it as fast as it can, or a filesystem layout that has a very bad hot-spot, then you could wear out a block much faster. But even then, if it is possible to spare-out a worn out block, you wouldn't be likely to lose enough blocks over 5 years to make a significant dent in the device's overall capacity. Let's look at this another way - how long would it take to wear out the entire device if you really tried? The typical erase time for a block is 2 ms, so if you never wrote, just erased over and over, you could do 100,000 erases in 200 seconds. There are 8192 erase blocks in a 1 GB NAND FLASH, so you could wear out the whole thing in 1.6 million seconds = 19 days. So you could wear out the device intentionally. But that is just erasing, not writing. If you write all the pages before erasing, it takes typically 0.2 mS to write a page, so writing all the pages of a block then erasing takes (64 * 0.2 mS) + 2 mS = 15 mS. So it would take 140 days to wear out the device by continuous writing/erasing. Continuous writing/erasing doesn't happen in any realistic workload, because most applications don't write data then immediately discard it. Oh, by the way, 100,000 cycles may be pessimistic. That is the data sheet rating, but I have heard that single-level NAND FLASH (like the ones we use) are coming in at more like 1 million erase cycles typical these days. The bottom line is that NAND wear-out is not likely to be an issue. JFFS2 does a good job of spreading out writes, and even if it only did a half-hearted job, that would probably be good enough. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
