EETimes

Embedded Systems December 2000 Vol13_13

Issue link: http://dc.ee.ubm-us.com/i/71850

Contents of this Issue

Navigation

Page 79 of 197

• TFS header: this is a per-file ove)-- FIGURE 1 Flash spaced used by TFS .. F1 F2 F3 , , , , 1 \ TFS HEADER: ushort hdrsize ushort version long filesize long flags ulong filcrc ulong hdrcrc ulong modtime struct tfshdr ' next char name[TFSNAMESIZEl char info[TFSINFOSIZEl Total flash space used by TFS F4 F5 ! Space available : for additional ...... ~ TFS files (F6, . F7, etc ... ) --- .... .... - .. ........ .......... Defragmentation Record Keeping Some space is needed at the end of file store space for record keeping during defragmentation. The actual amount of space needed depends on the number of active files in TFS at the time of defragmentation. ~~~~~'!"!'!~~~~~~~.- - -~ . co.n.c.e.rn.e. 1 .. ng o. , --------'I The spare sector must be at least as large as any other sector within the space used by TFS. ----~-""'- ""' - ""' --""' - "'!-""' --""'-.1 - ""' The only requirement regarding sector alignment is that I TFS start on a sector boundary. Files need not be size of the device must be at least as large as a sector for defragmentation to properly work. ry •.• d.w.i.th.o.v.e.rI.a.pP.i. __ a.s.ec.t.r.bo.u.n.d.a. T.h.e.se.c.to~r which fi les are stored. The spare sec- tor must be at least as large as any other sector in the device and the sec- tor prior to the spare is assumed to be of equal ize. TFS organizes the files within the flash in a contiguous one-way linked list. The initial portion of the fil e is a file header, which contains informa- tion about the fi le, pointe r to the next fi le, and 32-bit CRCs of the header and data portion of the fil e. Main taining unique CRC checks for header and data allow ' TFS to more accurately detect corruption. File size is limited only by the amount of flash allocated to TFS. There is no restric- tion with regard to sector boundaries. When th e sys tem is first built, TFS must be ini tialized . This means that the fl ash space allocated to TFS must be erased. From that point on, as a file is created it is appended to th e end of the linked list of fi les. If a fil e is deleted from th e list, it is simply ma rked as dele ted. At some point, afte ) - several files have been deleted , it becomes necessary to clean up th e TFS fl ash space by runn ing a defrag- mentation. This requires that a sec- tor be dedicated to the defragme n- tation process and it also uses a small block of fl ash at th e end of the TFS fl ash space for mainta ining a n on-vo latile sta te that can be retrieved in the event of an in ter- ru pted defragmen tation (power hi t or reset). Note th at the spare sector can not reside within the space used by TFS. It must be at the end because TFS assumes that all fil es are contiguous within the fl ash space it occupies. This, by the way, is a nice feature for extremely time-critical application. A data fil e can be stored in fl ash, accessed by name to retrieve the start- ing point of the data, and from that point on, simple (and more efficient) memory accesses can be made to read data from the memory space. It can be assumed by the application that the fi le data is in contiguous memory space. Flash space overhead required by TFS Overlaying TFS onto a fl ash device is not free. TFS requ ires a certain amount of space; some of that space is fixed; other space is based on the number of files stored. Referring to Figure 1, four portions of overhead must be considered: 78 DECEMBER 2000 Embedded Systems Programming I I J I ! .. Spare sector must be made available ; for power-safe , defragmentation head of 76 bytes. The value of 76 assumes that the sizes of the fil e- name and info field are each set to 23 (+1 for NULL termination) characters • Post-defragmentation header table: this is a table of fil e headers (plus defrag information) that is created at the end of the TFS space. One entry is created in this table for each "active" (non-deleted) file that exists at the time of a defrag- mentation. Each en try in the table is 100 bytes (assuming a header size of 76 bytes) • Defragmentation state table: th is is a table of states (bit fields) used by defragmentation. This overhead is equal to four times the number of sectors that are covered by TFS plus 16 • The spare sector: this is a sector of the fl ash that is used during defrag- mentation to copy in to. It must be at least as large as any other sector within TFS space Use the following equation to com- pute the total overhead introduced by TFS: overhead = (FTOT * ((HDRSIZE * 2) + 24» + SPARESIZE + (SECTOR- COUNT * 4) + 16 Where: • FTOT is the number of files to be stored • HDRSIZE is the size of a TFS file header (currently 76 bytes) • SPARESIZE is the size of the spare sector • SECTORCOUNT is the number of sectors allocated to TFS (not in cl uding spare) Note that a file that is marked as deleted in TFS requires less overhead than a file that is "livin g." This is because when a file is dead, there is no need to allocate a defragmenta- tion header to that fil e. This means

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems December 2000 Vol13_13