ubifs out-of-place update & Garbage Collection

原创译文：

在往 Flash 擦除块写数据(Write)之前必须将擦除块 （Erase Block）先进行擦除(Erase)操作。
Flash 擦除操作的最小单位是擦除块（Erase Block）, 写操作的最小单位是page。一般如下：
# mtdinfo /dev/mtd10
mtd10
Name:                           NAND (RW) Writable User area
Type:                           nand
Eraseblock size:                16384 bytes, 16.0 KiB
Amount of eraseblocks:          960 (15728640 bytes, 15.0 MiB)
Minimum input/output unit size: 512 bytes
Sub-page size:                  512 bytes
OOB size:                       16 bytes
Character device major/minor:   90:20
Bad blocks are allowed:         true
Device is writable:             true


现在看的这个例子中，NAND flash 擦除块的大小为16KB,flash 的总大小往往通过 Eraseblock size * Amount of eraseblocks 计算出来。
Page 的大小为 512 Bytes。


正是因为Flash这样的特点，为Flash 存储器设计的文件系统需要实现“不在原地更新”（Out-Of-Place update)。
如果擦除块很小，而且可以快速的擦除，那样的话擦除块就可以被视为块设备的 disk sectors，但是事实往往并非如此。读取一个擦除块中的数据，擦除这个擦除块，然后再将更新的数据写回这个擦除块往往比简单的直接将更新的数据写到另外一个已经被擦除过的擦除块多花费100倍的时间。也就是说，在原地更新数据（In-Place updates）往往比“不在原地更新”（Out-Of-Place Update）多用100倍的时间。


当然，Out-Of-Place update 也随之引入了其他的要求-- 垃圾回收（Garbage Collection）。 正是因为更新数据采用的Out-Of-Place， 擦除块就会既包含有效数据也包含被废弃的无效数据（有效数据已经被更新到其他地方）。 这样，最后文件系统会用光所有的擦除块，而一个擦除块将是有效数据和无效数据的结合体。 识别一个擦除块中含有很多废弃数据，并将其中的有效数据转移到另外的擦除块的过程被称为垃圾回收（Garbage Collection）。


垃圾回收得益于文件系统的节点结构（Node structure）。文件系统的垃圾回收器如果想回收一个擦除块，这个文件系统必须能够识别存在擦除块上的数据。这正是文件系统面临的查找索引的反向问题。文件系统往往通过文件名开始查找所有属于这个文件的数据。垃圾回收正好相反，垃圾回收是以数据作为起始线索，查找它所属于的文件（如果有的话）。解决这一问题的一种方式是把元数据(meta data)和文件数据(file data)一起存储。这种文件数据和数据的组合体称之为节点（node）。每个Node记录了这个node 中的元数据隶属于哪个文件（更确切的说是inode number），以及在文件中的offset 以及数据长度等。 JFFS2 和 UBIFS 文件系统都遵循了节点结构（node-structured）的设计模式,这使得它们的垃圾收集器可以直接读取擦除块就能可以知道哪些数据需要移动，哪些数据可以丢弃，并一一更新它们的索引。

A file system developed for flash memory requires out-of-place updates.This is because flash memory must be erased before it can be written to, and it can typically only be written once before needing to be erased again.

If eraseblocks were small and could be erased quickly, then they could be treated the same as disk sectors, however that is not the case.To read an entire eraseblock, erase it, and write back updated data typically takes 100 times longer than simply writing the updated data to a different eraseblock that has already been erased. In other words, for small updates, in-place updates can take 100 times longer than out-of-place updates.

Out-of-place updating requires garbage collection.As data is updated out-of-place, eraseblocks begin to contain a mixture of valid data and data which has become obsolete because it has been updated some place else.Eventually, the file system will run out of empty eraseblocks, so that every single eraseblock contains a mixture of valid data and obsolete data. In order to write new data somewhere, one of the eraseblocks must be emptied so that it can be erased and reused. The process of identifying an eraseblock with a lot of obsolete data, and moving the valid data to another eraseblock, is called garbage collection.

Garbage collection suggests the benefits of node-structure. In order to garbage collect aneraseblock, a file system must be able to identify the data that is stored there. This is the opposite of the usual indexing problem facing file systems. A file system usually starts with a file name and has to find the data that belongs to that file.Garbage collection starts with data that may belong to any file (or no file if it is obsolete) and must find which file, if any, it belongs to.

One way to solve that problem is to store metadata in line with the file data. This combination of data and metadata is called a node.Each node records which file (more specifically inode number) that the node belongs to and what data (for example file offset and data length) is contained in the node.Both JFFS2 and UBIFS follow a node-structured design, that enables their garbage collectors to read eraseblocks directly and determine what data needs to be moved and what can be discarded, and toupdate their indexes accordingly.