Re: NAND flash misery

Vladimir Vassilevsky wrote:
Stefan Reuther wrote:
Vladimir Vassilevsky wrote:
"David Brown" <david@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
The actual erase block size in NAND flash is something like
32/64/128/256KB,
being bigger for the higher capacity devices. What it implies: any write
operation through the IDE interface is actually read - copy - erase -
modify - write at the controller level.

Not if the implementor of the controller firmware did his homework.

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

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

If that's the case, a 512-byte block write ends up as a 512-byte block
write at the flash device, at a new address, and the old address is just
marked as unusable. No read/erase/modify/write for every operation.
Garbage compaction happens a some time in the background.

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.

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

.