Flash Space Overhead Required by TFS

Overlaying TFS onto a flash device is not free. TFS imposes a certain amount of overhead. Some of the extra space is fixed; some depends on the number of files stored. Referring to Figure 7.2, five portions of overhead must be considered :

• TFS Header a per file overhead of 92 bytes. The value of 92 assumes that the sizes of the name and info field are each set to 23 (+1 for NULL termination) characters and that the number of reserved entries is four.

• Post-Defragmentation Header Table this table of file headers (plus defragmentation information) resides at the end of the TFS space. TFS creates one entry in this table for each active (non-deleted) file that exists at the time of a defragmentation cycle.

• Defragmentation State Table two 32-bit CRCs for each sector. One CRC is computed on the sector before defragmentation and one CRC is computed after the sector has been processed by the defragmentation algorithm.

• Spare Sector a flash sector that the defragmentation algorithm uses for scratch pad space. The spare sector must be at least as large as any other sector within TFS space.

• Double Buffer when updating a file. In other words, if file A exists in TFS flash space, and, at some point file A is updated, the old file A is not deleted until the new file A is successfully created. The result is that the system must be prepared for the fact that, at one point in the file addition process, both the old and new file will exist.

Ignoring the double-buffer overhead, you use the following equation to compute the total overhead introduced by TFS:

overhead = ((FTOT * (HDRSIZE + DEFRAGHDRSIZE + 16)) + SPARESIZE + (SECTORCOUNT * 8))

Where:

• FTOT is the number of files to be stored.

• HDRSIZE is the size of a TFS file header (currently 92 bytes).

• DEFRAGHDRSIZE is the size of a TFS defragmentation header (currently 64 bytes)

• SPARESIZE is the size of the spare sector.

• SECTORCOUNT is the number of sectors allocated to TFS (not including spare).

Note that a file marked for deletion requires less overhead than an active file, because a deleted file does not require a defragmentation header. Thus deleting a file still frees up some memory space even though the file is not actually erased from the flash memory.