JFFS2 是一个开放源码的项目()。 它是在闪存上使用非常广泛的读/写文件系统，在嵌入式系统中被普遍的应用。这篇文章首先分析了在闪存上使用 JFFS2 的必要性，然后详细的阐述了 JFFS2 实现的内部机制，包括日志结构的文件系统，关键的数据结构，挂载过程和垃圾收集机制。同时也指出了 JFFS2 的局限性，并介绍了最新的针对 JFFS2 的不足进行改进的补丁程序。最后对 JFFS3 的设计思想和现在的开发状况给予了简单的介绍。
这一小节首先介绍了闪存相对于磁盘介质的特别之处，然后分析了将磁盘文件系统运行在闪存上的不足，同时也给出了我们使用 JFFS2 的理由。
这里所介绍的闪存的特性和限制都是从上层的文件系统的角度来看的，而不会涉及到具体的物理特性。总的来说，有两种类型的 flash memory: NOR flash 和 NAND flash. 先介绍一下这两种闪存所具有的共同特性。
A) 闪存的最小寻址单位是字节(byte)，而不是磁盘上的扇区(sector)。这意味着我们可以从一块闪存的任意偏移(offset)读数据，但并不表明对闪存写操作也是以字节为单位进行的。我们会在下面的阐述中找到答案。
B) 当一块闪存处在干净的状态时（被擦写过，但是还没有写操作发生），在这块flash上的每一位(bit)都是逻辑1。
C) 闪存上的每一位(bit)可以被写操作置成逻辑0。 可是把逻辑 0 置成逻辑 1 却不能按位(bit)来操作，而只能按擦写块（erase block）为单位进行擦写操作。擦写块的大小从 4K 到128K 不等。从上层来看，擦写所完成的功能就是把擦写块内的每一位都重设置（reset）成逻辑 1。
D) 闪存的使用寿命是有限的。具体来说，闪存的使用寿命是由擦写块的最大可擦写次数来决定的。超过了最大可擦写次数，这个擦写块就成为坏块(bad block)了。因此为了避免某个擦写块被过度擦写，以至于它先于其他的擦写块达到最大可擦写次数，我们应该在尽量小的影响性能的前提下，使擦写操作均匀的分布在每个擦写块上。这个过程叫做磨损平衡（wear leveling）。
NOR flash 与 NAND flash 的不同之处：
A) NOR flash 读/写操作的基本单位是字节；而 NAND flash 又把擦写块分成页(page), 页是写操作的基本单位，一般一个页的大小是 512 或 2K 个字节。对于一个页的重复写操作次数是有限制的，不同厂商生产的 NAND flash 有不同的限制，有些是一次，有些是四次，六次或十次。
B) 按照现在的技术水平，一般来说NOR flash擦写块的最大可擦写次数在十万次左右，NAND flash擦写块的最大可擦写次数在百万次左右。
将磁盘文件系统(ext2, FAT)运行在闪存上的很自然的方法就是在文件系统和闪存之间提供一个闪存转换层(Flash Translation Layer), 它的功能就是将底层的闪存模拟成一个具有 512字节扇区大小的标准块设备(block device)。对于文件系统来说，就像工作在一个普通的块设备上一样，没有任何的差别。
一个闪存转换层的最简单的实现就是将模拟的块设备一对一的映射到闪存上。举例来说，当上层的文件系统要写一个块设备的扇区时，闪存转换层要做下面的操作来完成这个写请求：
1 将这个扇区所在擦写块地数据读到内存中，放在缓存(buffer)中
2 将缓存中与这个扇区对应的内容用新的内容替换掉
3 对该擦写块执行擦写操作
4 将缓冲中的数据写回该擦写块
这种实现方式的缺点是很明显的：
1 效率低，对一个扇区的更新要重写整个擦写块上的数据，造成数据带宽很大的浪费。
2 没有提供磨损平衡，那些被频繁更新的数据所在擦写块将首先变成坏块。
3 非常不安全，很容易引起数据的丢失。如果在上面的第三步和第四步之间发生了突然掉电(power loss)，那么整个擦写块中的数据就全部丢失了。这在突然掉电经常发生的嵌入式系统中是不能接受的。
MTD 中的内核模块 mtdblock 就是基于这种机制实现的，同时还作了一些优化。只有当文件系统的写请求超过了一个擦写块的边界的时候，它才会执行对闪存的擦写，写回操作。
因此，为了解决上面这种实现方式的问题，闪存转换层需要做更多的事情。闪存转换层不能只实现这种一对一的映射，而需要将模拟块设备的扇区存储在闪存的不同位置，并且维持扇区到闪存的映射关系。更进一步，闪存转换层还必须能理解上层文件系统的语义，否则闪存转换层没办法做垃圾回收(Garbage Collection)。这样实现最大的问题就是效率不高，具体来说，闪存转换层为了能理解上层文件系统的语义，必须对文件系统的每个写请求进行解析，这势必带来写操作性能的下降。另外要求文件系统下面的一层去理解文件系统的语义，很显然这不是最好的解决方式。我们还有很好的解决问题的方法，就是实现一个特别针对闪存的文件系统。而 JFFS2 就是一个这样的文件系统。
有 JFFS2 就要有 JFFS v1，没错，JFFS v1 最初是由瑞典的 Axis Communications AB 公司开发的，使用在他们的嵌入式设备中，并且在 1999 年末基于 GNU GPL 发布出来。最初的发布版本基于 Linux 内核 2.0，后来 RedHat 将它移植到 Linux 内核 2.2，做了大量的测试和 bug fix 的工作使它稳定下来，并且对签约客户提供商业支持。但是在使用的过程中，JFFS v1 设计中的局限被不断的暴露出来。于是在 2001 年初的时候，RedHat 决定实现一个新的闪存文件系统，这就是现在的 JFFS2。下面将详细介绍 JFFS2 设计中主要的思想，关键的数据结构和垃圾收集机制。这将为我们实现一个闪存上的文件系统提供很好的启示。首先，JFFS2 是一个日志结构(log-structured)的文件系统，包含数据和原数据(meta-data)的节点在闪存上顺序的存储。JFFS2 之所以选择日志结构的存储方式，是因为对闪存的更新应该是 out-of-place 的更新方式，而不是对磁盘的 in-place 的更新方式。在闪存上 in-place 更新方式的问题我们已经在闪存转换层一节描述过了。
JFFS2 将文件系统的数据和原数据以节点的形式存储在闪存上，具体来说节点头部的定义如下：
幻数屏蔽位：0x1985 用来标识 JFFS2 文件系统。
节点类型：JFFS2 自身定义了三种节点类型，但是考虑到文件系统可扩展性和兼容性，JFFS2从 ext2 借鉴了经验，节点类型的最高两位被用来定义节点的兼容属性，具体来说有下面几种兼容属性：
JFFS2_FEATURE_INCOMPAT：当 JFFS2 发现了一个不能识别的节点类型，并且它的兼容属性是 JFFS2_FEATURE_INCOMPAT，那么 JFFS2 必须拒绝挂载(mount)文件系统。
JFFS2_FEATURE_ROCOMPAT：当 JFFS2 发现了一个不能识别的节点类型，并且它的兼容属性是 JFFS2_FEATURE_ROCOMPAT，那么 JFFS2 必须以只读的方式挂载文件系统。
JFFS2_FEATURE_RWCOMPAT_DELETE：当 JFFS2 发现了一个不能识别的节点类型，并且它的兼容属性是 JFFS2_FEATURE_RWCOMPAT_DELETE，那么在垃圾回收的时候，这个节点可以被删除。
JFFS2_FEATURE_RWCOMPAT_COPY：当 JFFS2 发现了一个不能识别的节点类型，并且它的兼容属性是 JFFS2_FEATURE_RWCOMPAT_COPY，那么在垃圾回收的时候，这个节点要被拷贝到新的位置。
节点总长度：包括节点头和数据的长度。
节点头部 CRC 校验：包含节点头部的校验码，为文件系统的可靠性提供了支持。
JFFS2 定义了三种节点类型：
JFFS2_NODETYPE_INODE： INODE 节点包含了i-节点的原数据(i节点号，文件的组 ID, 属主 id, 访问时间，偏移，长度等)，文件数据被附在 INODE 节点之后。除此之外，每个 INODE 节点还有一个版本号，它被用来维护属于一个i-节点的所有 INODE 节点的全序关系。下面举例来说明这个全序关系在 JFFS2 的使用：
因此，当文件系统从闪存上读节点信息后，会生成下面的映射信息：
根据这个映射信息表，文件系统就知道到相应的 INODE 节点去读取相应的文件内容。最后要说明的是，JFFS2 支持文件数据的压缩存储，因此在 INODE 节点中还包含了所使用的压缩算法，在读取数据的时候选择相应的压缩算法来解压缩。
JFFS2_NODETYPE_DIRENT：DIRENT 节点就是把文件名与 i 节点对应起来。在 DIRENT节点中也有一个版本号，这个版本号的作用主要是用来删除一个 dentry。具体来说，当我们要从一个目录中删除一个 dentry 时，我们要写一个 DIRENT 节点，节点中的文件名与被删除的 dentry 中的文件名相同，i 节点号置为 0，同时设置一个更高的版本号。
JFFS2_NODETYPE_CLEANMARKER：当一个擦写块被擦写完毕后，CLEANMARKER 节点会被写在 NOR flash 的开头，或 NAND flash 的 OOB(Out-Of-Band) 区域来表明这是一个干净，可写的擦写块。在 JFFS v1 中，如果扫描到开头的 1K 都是 0xFF 就认为这个擦写块是干净的。但是在实际的测试中发现，如果在擦写的过程中突然掉电，擦写块上也可能会有大块连续 0xFF，但是这并不表明这个擦写块是干净的。于是我们需要 CLEANMARKER 节点来确切的标识一个干净的擦写块。
JFFS2 维护了几个链表来管理擦写块，根据擦写块上的内容，一个擦写块会在不同的链表上。具体来说，当一个擦写块上都是合法(valid)的节点时，它会在 clean_list 上；当一个擦写块包含至少一个过时(obsolete)的节点时，它会在 dirty_list 上；当一个擦写块被擦写完毕，并被写入 CLEANMARKER 节点后，它会在 free_list 上。
通常情况下，JFFS2 顺序的在擦写块上写入不同的节点，直到一个擦写块被写满。此时 JFFS2 从 free_list 上取下一个擦写块，继续从擦写块的开头开始写入节点。当 free_list 上擦写块的数量逐渐减少到一个预先设定的阀值的时候，垃圾回收就被触发了，为文件系统清理出更多的可用擦写块。为了减少对内存的占用，JFFS2 并没有把 i 节点所有的信息都保留在内存中，而只是把那些在请求到来时不能很快获得的信息保留在内存中。具体来说，对于在闪存上的每个 i 节点，在内存里都有一个 struct jffs2_inode_cache 与之对应，这个结构里保存了 i 节点号，指向 i 节点的连接数，以及一个指向属于这个 i 节点的物理节点链表的指针。所有的 struct jffs2_inode_cache 存储在一个哈希表中。闪存上的每个节点在内存中由一个 struct jffs2_raw_node_ref 表示，这个结构里保存了此节点的物理偏移，总长度，以及两个指向 struct jffs2_raw_node_ref 的指针。一个指针指向此节点在物理擦写块上的下一个节点，另一个指针指向属于同一个 i-节点的物理节点链表的下一个节点。
在闪存上的节点的起始偏移都是 4 字节对齐的，所以 struct jffs2_inode_cache 中flash_offset 的最低两位没有被用到。JFFS2 正好利用最低位作为此节点是否过时的标记。
下面举一例来说明 JFFS2 是如何使用这些数据结构的。VFS 调用 iget() 来得到一个 i 节点的信息，当这个 i 节点不在缓存中的时候，VFS 就会调用 JFFS2 的 read_inode() 回调函数来得到 i 节点信息。传给 read_inode() 的参数是 i 节点号，JFFS2 用这个 i 节点号从哈希表中查找相应的 struct jffs2_inode_cache，然后利用属于这个 i 节点的节点链表从闪存上读入节点信息，建立类似于表三的映射信息。
JFFS2 的挂载过程分为四个阶段：
1) JFFS2 扫描闪存介质，检查每个节点 CRC 校验码的合法性，同时分配了 struct jffs2_inode_cache 和 struct jffs2_raw_node_ref
2) 扫描每个 i 节点的物理节点链表，标识出过时的物理节点；对每一个合法的 dentry 节点，将相应的 jffs2_inode_cache 中的 nlink 加一。
3 找出 nlink 为 0 的 jffs2_inode_cache，释放相应的节点。
4 释放在扫描过程中使用的临时信息。
当 free_list 上的擦写块数太少了，垃圾回收就会被触发。垃圾回收主要的任务就是回收那些已经过时的节点，但是除此之外它还要考虑磨损平衡的问题。因为如果一味的从 dirty_list上选取擦写块进行垃圾回收，那么 dirty_list 上的擦写块将先于 clean_list 上的擦写块被磨损坏。JFFS2 的处理方式是以 99% 的概率从 dirty_list，1% 的概率从 clean_list 上取一个擦写块下来。由此可以看出 JFFS2 的设计思想是偏向于性能，同时兼顾磨损平衡。对这个块上每一个没有过时的节点执行相同的操作：
1 找出这个节点所属的 i 节点号(见图五)。
2 调用 iget()，建立这个 i 节点的文件映射表。
3 找出这个节点上没有过时的数据内容，并且如果合法的数据太少，JFFS2 还会合并相邻的节点。
4 将数据读入倒缓存里，然后将它拷贝到新的擦写块上。
5 将回收的节点置为过时。
当擦写块上所有的节点都被置为过时，就可以擦写这个擦写块，回收使用它。
JFFS2 的挂载过程需要对闪存从头到尾的扫描，这个过程是很慢的，我们在测试中发现，挂载一个 16M 的闪存有时需要半分钟以上的时间。
JFFS2 对磨损平衡是用概率的方法来解决的，这很难保证磨损平衡的确定性。在某些情况下，可能造成对擦写块不必要的擦写操作；在某些情况下，又会引起对磨损平衡调整的不及时。
JFFS2 中有两个地方的处理是 O(N) 的，这使得它的扩展性很差。
首先，挂载时间同闪存的大小，闪存上节点数目成正比。
其次，虽然 JFFS2 尽可能的减少内存的占用，但通过上面对 JFFS2 的介绍我们可以知道实际上它对内存的占用量是同 i 节点数和闪存上的节点数成正比的。
因此在实际应用中，JFFS2 最大能用在 128M 的闪存上。
最近加入到 JFFS2 中的两个补丁程序分别解决了上面提到的挂载时间过长和磨损平衡随意性的问题。
这个补丁程序最基本的思想就是用空间来换时间。具体来说，就是将每个擦写块每个节点的原数据信息写在这个擦写块的最后，当 JFFS2 挂载的时候，对每个擦写块只需要读一次来读取这个小结节点，因此大大减少了挂载时间。使用了磨损块小结补丁程序，一个擦写块的结构就像下面这样：
根据我们的测试，使用磨损块小结补丁程序，挂载一个 12M 的闪存需要 2~3 秒，挂载一个 16M 的闪存需要 3~4 秒。
这个补丁程序的基本思想是，记录每个擦写块的擦写次数，当闪存上各个擦写块的擦写次数的差距超过某个预定的阀值，开始进行磨损平衡的调整。调整的策略是，在垃圾回收时将擦写次数小的擦写块上的数据迁移到擦写次数大的擦写块上。这样一来我们提高了磨损平衡的确定性，我们可以知道什么时候开始磨损平衡的调整，也可以知道选取哪些擦写块进行磨损平衡的调整。
在写改进的磨损平衡补丁程序的过程之中，我们需要记录每个擦写块的擦写次数，这个信息需要记录在各自的擦写块上。可是我们发现 JFFS2 中缺少一种灵活的对每个擦写块的信息进行扩展的机制。于是我们为每个擦写块引入了擦写块头部(header)，这个头部负责纪录每个擦写块的信息(比如说擦写次数)，并且它提供了灵活的扩展机制，将来如果有新的信息需要记录，可以很容易的加入到头部之中。
虽然不断有新的补丁程序来提高 JFFS2 的性能，但是不可扩展性是它最大的问题，但是这是它自身设计的先天缺陷，是没有办法靠后天来弥补的。因此我们需要一个全新的文件系统，而 JFFS3 就是这样的一个文件系统，JFFS3 的设计目标是支持大容量闪存(>1TB)的文件系统。JFFS3 与 JFFS2 在设计上根本的区别在于，JFFS3 将索引信息存放在闪存上，而 JFFS2将索引信息保存在内存中。比如说，由给定的文件内的偏移定位到存储介质上的物理偏移地址所需的信息，查找某个目录下所有的目录项所需的信息都是索引信息的一种。 JFFS3 现在还处于设计阶段，文件系统的基本结构借鉴了 Reiser4 的设计思想，整个文件系统就是一个 B+ 树。JFFS3 的发起者正工作于垃圾回收机制的设计，这是 JFFS3 中最复杂，也是最富有挑战性的部分。JFFS3 的设计文档可以在 得到，有兴趣的读者可以积极参与到 JFFS3 的设计中，发表自己的见解，参与讨论。
在这里要特别感谢David Woodhouse, Artem B. Bityutskiy，Joern 和 Thomas Gleixner，在参与到JFFS2的开发过程中，这几位主要的项目维护者(maintainer)不断地给我帮助，耐心的回答我的问题，在与他们的讨论过程中碰撞出很多智慧的火花和富有启发性的思想，尤其是他们对我的补丁程序提出的”尖刻”的问题，让我不断的努力思考(thinking hard)，不断的完善它们。我想这种开放，无私，客观的精神正是开源社区的精髓所在，吸引着越来越多的开发者参与进来，并使开源社区不断的壮大。
