Prolonging Flash Memory Life

Flash memory has a huge limitation — the number of times you can rewrite each of its sectors is limited to around 100,000 times. At first this may seem like a virtually unreachable limit, but in reality you can "get there" quite fast, which is not a good thing. Once the flash wears down, you will start having data errors, data corruption, failed sectors, etc. This topic explains what you can do to prolong the life of the flash memory used in your device. This is generally achieved by (1) reducing the number of writes to the flash memory and (2) using sector leveling (i.e., spreading sector writes, as evenly as possible, between the sectors).

File-Based Access

For file-based access, the fd. object does the bulk of work for you. We have already explained that the file record table (FRT) and the file allocation table (FAT) — the most heavily written to areas of the disk — occupy at least double the space needed to store their data. They also have the minimum number of sectors they will take, regardless of what is necessary. This ensures that at any given time, the FRT and the FAT have spare sectors. These spare sectors, as well as occupied sectors, are in constant rotation.

For example, every time you create a file, a change is made to one of the sectors of the FRT. This change requires writing data to one of the physical sectors. In the process, the fd. object will take the previously used FRT sector and "release it" into the pool of spare FRT sectors. At the same time, one of the spare FRT sectors will become active and store changed data. The FAT operates in the same manner. While being fully transparent to your application, the process greatly prolongs useful flash memory life.

You can, and are advised to, further reduce the wear of the FAT and FRT by decreasing the number of writes that will be required. One way to do so is to create all necessary files and allocate space for them once — typically when your application "initializes" your device.

Say you have a log file that stores events collected by your application. An obvious approach would be to simply append each new event's data to the file. This way, the file will grow with each event added. But, wait a second, this means that the FRT area, which keeps current file size, will be changed each time you add to the file! The FAT area will be stressed too!

An alternative approach would be to create a file with a desired maximum size once and fill it up with "blank" data (such as &hFF codes). We then overwrite this blank data with actual event data as events are generated. This time around, our actions will be causing no changes in the FRT and FAT areas, thus prolonging the life of the flash IC.

Not only does this approach prolong the life of the flash IC, but disk writing to the log will be faster (less sectors to change), and, in case you use transactions, less journal entries will be used (a single transaction can fit more operations).

When using transactions, do allow a generous space for the journal memory. The recommended maxjournalsectors value for fd.formatj is 50-100. Journal memory is a high-traffic disk area, so having more sectors there will improve flash memory life.

The data area of the disk has limited leveling that results in spreading unused sector utilization. The fd. object makes sure that when your file needs a new data sector, this data sector will be selected from a pool of available data sectors in a random fashion. Once the data sector has been allocated to a file, however, it stays with that file for as long as necessary. So, if you are writing at a certain file offset over and over again, you are stressing the same physical sector of the flash IC.

On large files, you rarely write at the same offset all the time. For example, if you have a log file that has 1,000 data sectors, then it is unlikely you will be writing to the same sector over and over again. For smaller files, the probability is higher. Your solution is to erase the file and recreate it again from time to time. This will randomly allocate new sectors for the file.

Direct Sector Access

Direct sector access is a low-level form of working with the flash. You are your own master, the fd. object does not help you with anything and it is up to you to make sure that the flash IC is not being worn out unevenly. Generally speaking, limit the number of times you are writing to the flash and/or implement some form of leveling where a large number of sectors are used to share the same task and each sector gets its fair share of work.