First Erase Block mode

Figure 6: CS block

• Mount
  The entry point of Centralized Summary is after the inodecache is allocated. It allocates its own structure (c->cs_struct) and inicializes it. CS calls a special building function to determine the status of the first three eraseblocks. If the first three eraseblock are marked as bad then CS is disabled and works as without CS support. If it finds a not bad block then sets c->cs_struct->csblock to points to this eraseblock and reads the content of the csblock. CS differentiate five different case depending on the content.
  1. csblock contains only CS log node and the last node is an unmount log and it is loaded, CS data is processed
  2. csblock contains only CS log node and the last node is an mount log
  3. csblock is empty or contains not log data
  4. csblock contains only CS log node and the last node is an unmount log but the CRC checksum of the node is wrong
  5. csblock contains only CS log node and the last node is an unmount log and it is loaded but error occured during the processing of the cs data
  In case 1 everything is all right, the last unmount was clean. cs_flags's valid field is set to true.

  In case 2 the last unmount was not clean. It means there is no valid CS data on flash and normal scan have to run down. cs_flags' valid field is set to true.

  In case 3 the csblock is not valid and the valid flag is set to false. All of the contents must be replaced after the normal scan process, after the replacement the eraseblock is erased and used only for storing CS log nodes.

  In case 4 the csblock may have bad area and the data can be wrong. The valid flag is set to true. csblock is erased and normal scan runs.

  In case 5 the CS data is wrong CS writes a mount log. If not clean unmount comes then the next mount time CS will know that the last umount log is not valid. The valid flag is set to true and normal scan runs.

• File operations
  File operations are the same as without CS.
• Unmount
  CS starts its operation when GC thread stopped during the umount. CS saves the necessary part of the memory structures that JFFS2 uses. These structures are the followings: jffs2_inode_cache, jffs2_eraseblock, jffs2_raw_node_ref, c lists. With the help of this information the state of the fs can be restored at next mount.
  • Dumping inode cache
    CS tries to allocate at least sizeof(CS ic node) + JFFS2_MIN_INOCACHE_NUM * JFFS2_INOCACHE_ENTRY_SIZE space on flash whereto CS stores the ic data. The stored data entry of CS ic node is centsum_ino_cache. If CS can't get the minimum required space then CS exits and the normal unmount is continued. If it gets the space, then allocates a memory buffer whereto it can compose the CS ic dump. If there are so many inodes that CS cant dump it into one CS ic node then CS writes out as many inode as it can and then allocates space on flash again and writes the next CS ic node.
  • Dumping jebs (eraseblocks)
    It is the same situation as in ic dump but here it allocates sizeof(CS jebinfo node) + JFFS2_MIN_JEBINFO_NUM * JFFS2_JEBINFO_ENTRY_SIZE space and the stored entry is cent_sum_jeb.
  • Dumping raw node references
    It is the same situation as in ic dump but it allocates sizeof(CS rawref node) + JFFS2_MIN_RAWREF_NUM * JFFS2_RAWREF_ENTRY_SIZE and the stored entry is cent_sum_rawref.
  • Dumping c lists
    This case is different because here CS must reserve the necessary space as one block, here CS can't split the data into smaller parts. See the description of struct jffs2_cent_sum_lists_node for storage method.
  • Writing umount log
    If all data is dumped then CS writes an umount log into the csblock. The mount and the umount log are using the same structure but mount log's valid field is 0 opposing the umount log where it is 1 and umount log uses the offset list where it stores the offsets whence CS can load the saved data.