One of the common refrains about using CompactFlash as a hard disk replacement is that it has a limited number of “writes” (reads don’t impact lifespan). This is a major concern for a potential Zonbu owner. Is that card going to burn out in the next year or two?
I’ve done some Internet research, and while “don’t use it in a high frequency write environment as it will ‘burn out’ the card” is a common refrain, I could not find any hard statistics on the lifespan of modern cards. Thankfully, it looks like the Zonbu team has done some testing in this regard…
This would have been the case a few year ago. Modern CF cards controllers implement block rotation in hardware, which means that the swap is not always written on the same blocks.
We evaluated that it would take 10 years continuously writing on the card before the failure risk becomes significant.
_________________
Aymeric
Zonbu Engineering Team
While I have to say that I feel better hearing that, I find it a bit strange that no one from the CF industry has that kind of info on their site.
Conservatively, I’m planning on a 3 year lifespan for the cards I’m using in servers at the office. 10 seems a bit optimistic, but maybe I’m just cautious…
-Mr. Zonbu
Real life with the Zonbu Mini-PC 
I’m not an expert but here is what I have learned in the past few months. There are two kinds of flash memory: SLC and MLC. SLC flash is rated at approximately 100000 cycles and MLC flash is rated to have approximately 10000 cycles. But then it’s more complex because the controller of the flash card is able to rotate the blocks. It’s called the dynamic wear-leveling. You can then do the maths with the IDE bandwidth and if you take the assumption that a user is written all the time.
There are a couple of points I want to mention:
– we have currently distributed two kinds of CF: Ritek 133x and SanDisk Extreme III. Note that those cards have been put under heavy stress though we don’t have a three-year 😉 history to really know what will happen. Zonbu has a three-year warranty so as to comply with the EPEAT gold certification. If for any reason, your CF card dies, we will exchange it.
– If you really want to build a model for the CF lifetime, you should take into account that the swap space is also written to the card. A swap partition is much more intensive than the standard user data partition because writes are very random and could be very frequent. It’s the worst case scenario for a CF controller.
I’ve been heavily involved in flashbased computers for over 6 years, and have never had a failure due to writes.
Last time that I checked, CF manufacturers were not listing MTBF in write cycles, but in continuous hours, as in > 1 million hours of continuous use.
Simply put, there is no truth to modern CF’s wearing out due to write cycles.
i’ve been wondering about this too. here is a 40 pin “industrial” flash module that claims “…R/W endurance of 4,000,000 times, wear-leveling algorithm, and support for most operating systems…”
i don’t know if 4 million read/writes is impressive or not. $80USD isn’t exactly inexpensive for a 2GB flash unit, but might be worth it if “industrial” is actually better than a basic CF.
Hello. Currently I am doing some test with compact flash (NAND) with constantly writing, deleteing, reading cycle with 2,5 MB file. I am writing some random data and the card is connected to the computer thourgh IDE (as it would be disk). I have partitioned the compact flash to several partitions and the partition on which i am doing test is 10 MB large. Beside dynamic generated and deleted file there is also static file with size about 6 MB. My purpose of this test is try to destroy some avaliable spare blocks. So far no results were seen (done about 1 million cycles) on compact flash. I am interested if there is any known analysis on this theme, how number of spare blocks is gradualy lowered due to their use to remove the data from bad block to new (spare) block. Together with my s-tech 1GB compact flash i have also windows app with wich i can see how many spare blocks are left there on the card.
With respect to what Gorazd is doing, just an FYI… despite partitioning the CF, the memory controller’s wear levelling algorithm still distributes reads across the entire card, transparently. The test will not show how fast you can burn out a 10mb card, but rather the whole card.
I’d love to know if the FAT itself can be wear-leveled. From what I’ve read, the suggestion is that the FAT exists within a specific address range, with this table being updated constantly…