blindfold wrote: > My understanding is that a flash cell normally contains one or (in > multilevel storage) two bits of data. Moreover, in my example I am > writing to every available bit, so the chunk size is irrelevant as > this leaves no room to spread the cell load over more cells through > wear-leveling algorithms, or "seamlessly change the mappings" as you > put it. Error correction codes and spare cells, if present, could > indeed help, but I have not heard that these are commonly applied in > the kinds of low-cost flash memory devices that we are talking about > here.
Um, no. You can only erase flash in large chunks --- these are the cells. Each physical cell can only be erased so many times. Erasing a cell can take a very long time (like, a second). The microcontroller keeps a mapping of what logical disk block is stored in which flash cell. When you ask the SD card to write to a particular logical block, the microcontroller will *pick a different cell*, one that it's already erased, and copy all the data from the old cell into it (with the changes you specify). Then it starts the erase process on the old cell in the background so that eventually the old cell will become empty and can be reused. This means that if you write to the same *logical* block 10000 times, you're probably going to be writing to 10000 different cells once. So instead of using up all the erases in one cell, you've merely used up 1/10000th of the erases in 10000 cells. Wear levelling is an extension of this which *ensures* that you're going to be writing to 10000 different cells, so keeping the overall wear constant across the device rather than being concentrated in particular cells --- very important when using file systems like FAT. Here are some figures: Assuming a 64kB cell size, which seems reasonable, a 1GB flash card will contain 16384 cells. Each cell can be erased 10000 times. (In fact, cheapo SD cards these days are more like a million.) This means that you can write to a cell 163840000 times on the card, approximately, before it dies of old age; this is about 10TB of writes. Your sample application is MP3 streaming. Streaming at 128kbs will involve writing 16kB/sec which means you need to write a cell every 4 seconds. (And because it's a nice simple stream, buffering will ensure that you're only flushing a cell when necessary rather than having to write partial cells, which will of course use up your quota faster.) This means you get 163840000*4 = 655360000 seconds = 21 years of MP3 streaming before your SD card gives up the ghost. You give a pathological example of a 128MB card that's 90% full. This means there are only 204 cells, which means only 2040000 writes, which comes to 8160000 seconds = 94 days. That's still a lot. In fact, you can't get 128MB SD cards any more; even when you could they used much smaller cell sizes; the SD card microcontroller keeps spare cells around for just this situation; and every time the user writes to one of the other 90%, it'll give the microcontroller the chance to rearrange the cells again, which means you'll get another 10000 or so writes, which gives you another 11 hours. This really isn't a problem any more. Flash devices these days generally have longer lifetimes than hard disks. (Although you *are* at the mercy of the SD card vendor's microcontroller. I've heard rumours of some bad SD cards where the microcontroller stored the whole wear map in a single cell --- which wasn't wear levelled. Yeah, like that's going to work. But in my entire career, I have met *one* person who has had a flash device die of old age.) -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── │ │ "All power corrupts, but we need electricity." --- Diana Wynne Jones, │ _Archer's Goon_
signature.asc
Description: OpenPGP digital signature
