Not exactly. The 4MB zone is just the area that they give 3 percent additional
memory cells. Each 4MB zone would have the extra 3 percent. The extra cells
and wear leveling are why the flash products are usable in cameras and other
things. Back in the day when the first products appeared the flash parts had
limited writes. You might only be able to write to a part 10,000 times before
it failed. The actual block size could be as small as a byte depending on the
card. The SanDisk patents use the term zone ambiguously as do the documents as
previously noted by Jim D.(This is most annoying). SanDisk uses smaller zones
or blocks and records the number of uses per zone or block. According to the
patents the last generation of parts had something on the order of a 100,000
writes per cell before the write / erase cycles take to long. The cells do not
actually wear out they just take a progressively longer time to read or write
to. SanDisk spreads the write / erase cycles over the whole part as evenly as
possible. This is transparent to the user of the card just like a modern hard
drive. You are not actually writing to the same portion of the flash chip even
if you send the card the same address. The card is moving them around for you
to manage the wear leveling.
Bobby
----- Original Message -----
From: Michael Schnell
To: uClinux development list
Sent: Friday, March 27, 2009 2:23 AM
Subject: Re: [uClinux-dev] SD card corruption upon reboot and de-power
Bobby Clark wrote:
Based on a 4MB zone and a 3 % reserve block there would be 120k bytes of
reserve bytes per 4MB zone.
I suppose 4 MB is the size of the block that needs to erased in a single
step. (The smaller the blocks the more expensive the chip.)
So with any FAT update you get one down from the 100,000 wear out count of
the complete 4 MB Block. After that you (might) need a new one from the 3%
spare 4 MB blocks.
-Michael
------------------------------------------------------------------------------
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
