NAND flash misery

This is what described in the appnotes from Samsung and Sandisk.

So something like FAT or MFT has to be maintained internally, and it has to be done in the background instead of by every transaction. This scheme doesn't seem to be very applicable for the removable media.

There is a very significant penalty in the speed of the flash write operation at the IDE level if the short blocks are used. The difference can be as high as 10 times or so. According to the appnotes, this happens due to the read - modify - write thing.

VLV

Modern hard disks rely (heavily) on ECC too, likewise a hard disk can spot blocks becoming bad before they become unrecoverable. In other words: the situation for traditional hard disks is not that different.

Also the number of spin-ups of ordinary HDD's is only guaranteed to about 50.000 cycles. This can be a limiting factor when one needs to employ aggressive power saving strategies.

Interesting. Failure-prone for removable media, and reduces the part's life time :->

The remapping table can be reconstructed at any time from the data on the media. The scheme is called log-structured file system. The implementations I've seen so far (Green Hills and YAFFS, although I've only started looking closer at the latter) work this way.

Stefan

Not really. When you think about it, writes and read-modify-writes are the embedded controller's only easy opportunity for moving frequently modified data to a less used block - this is the easy change to accomplish wear leveling.

I would also assume that enough energy can be stored in an on-card capacitor to flush a full block write from cache ram to the NAND, at least provided that the destination is already erased, which you'd probably do premptively since the destination is going to be a different (less worn) location anyway.

Le Sun, 29 Jun 2008 09:53:28 -0500, Vladimir Vassilevsky a écrit:

And i bow in front of you Vlad or should i say in front of your wisdom.

Really ?

Robust ???? Compatible ???? To meet these conditions i suggest to avoid using NAND Flash based technology.

If I had the ultimate solution for data storage I would probably be on a beach in the bahamas with charming creatures around me :-)

it

not

Eh? Wasn't it said to bow to the _opportunity_ ?

es

Yes. But don't get a swelled head.

If your goal is beach with charming creatures, you are perhaps in the=20 wrong kind of business for that. Even the ultimate storage solution=20 won't help.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

I don't follow this logic; are you saying that for statistically average usage in a system that doesn't thrash, wear-leveling on a larger device has more room to work and thus has a longer life-cycle? Doesn't this argument fall apart with modern VM o/s usage and thrashing?

Michael

Modern OS's (even windows) do not thrash unless you try to run too much with too little ram.

And yes, if you have a larger disk to spread the writes, then there will be fewer erase/writes per block for the same amount of write usage - that's fairly obvious maths.

And even if you do occasionally thrash the swap file or swap partition, the argument still applies - a larger disk will last longer.