JFFS2文件系统及新特性介绍
1． 为什么需要 JFFS2这一小节首先介绍了闪存相对于磁盘介质的特别之处，然后分析了将磁盘文件系统运行在闪存上的不足，同时也给出了我们使用 JFFS2 的理由。
1.1 闪存(Flash Memory) 的特性和限制
这里所介绍的闪存的特性和限制都是从上层的文件系统的角度来看的，而不会涉及到具体的物理特性。总的来说，有两种类型的 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擦写块的最大可擦写次数在百万次左右。
1.2 闪存转换层
将磁盘文件系统(ext2, FAT)运行在闪存上的很自然的方法就是在文件系统和闪存之间提供一个闪存转换层(Flash Translation Layer), 它的功能就是将底层的闪存模拟成一个具有 512字节扇区大小的标准块设备(block device)。对于文件系统来说，就像工作在一个普通的块设备上一样，没有任何的差别。
图一
一个闪存转换层的最简单的实现就是将模拟的块设备一对一的映射到闪存上。举例来说，当上层的文件系统要写一个块设备的扇区时，闪存转换层要做下面的操作来完成这个写请求：
1 将这个扇区所在擦写块地数据读到内存中，放在缓存(buffer)中
2 将缓存中与这个扇区对应的内容用新的内容替换掉
3 对该擦写块执行擦写操作
4 将缓冲中的数据写回该擦写块
这种实现方式的缺点是很明显的：
1 效率低，对一个扇区的更新要重写整个擦写块上的数据，造成数据带宽很大的浪费。
2 没有提供磨损平衡，那些被频繁更新的数据所在擦写块将首先变成坏块。
3 非常不安全，很容易引起数据的丢失。如果在上面的第三步和第四步之间发生了突然掉电(power loss)，那么整个擦写块中的数据就全部丢失了。这在突然掉电经常发生的嵌入式系统中是不能接受的。
MTD 中的内核模块 mtdblock 就是基于这种机制实现的，同时还作了一些优化。只有当文件系统的写请求超过了一个擦写块的边界的时候，它才会执行对闪存的擦写，写回操作。
因此，为了解决上面这种实现方式的问题，闪存转换层需要做更多的事情。闪存转换层不能只实现这种一对一的映射，而需要将模拟块设备的扇区存储在闪存的不同位置，并且维持扇区到闪存的映射关系。更进一步，闪存转换层还必须能理解上层文件系统的语义，否则闪存转换层没办法做垃圾回收(Garbage Collection)。这样实现最大的问题就是效率不高，具体来说，闪存转换层为了能理解上层文件系统的语义，必须对文件系统的每个写请求进行解析，这势必带来写操作性能的下降。另外要求文件系统下面的一层去理解文件系统的语义，很显然这不是最好的解决方式。我们还有很好的解决问题的方法，就是实现一个特别针对闪存的文件系统。而 JFFS2 就是一个这样的文件系统。
  |
|
2. 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 更新方式的问题我们已经在闪存转换层一节描述过了。
2.1 节点头部定义和兼容性
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 校验：包含节点头部的校验码，为文件系统的可靠性提供了支持。
2.2 节点类型
JFFS2 定义了三种节点类型：
JFFS2_NODETYPE_INODE： INODE 节点包含了i-节点的原数据(i节点号，文件的组 ID, 属主 id, 访问时间，偏移，长度等)，文件数据被附在 INODE 节点之后。除此之外，每个 INODE 节点还有一个版本号，它被用来维护属于一个i-节点的所有 INODE 节点的全序关系。下面举例来说明这个全序关系在 JFFS2 的使用：
图三
因此，当文件系统从闪存上读节点信息后，会生成下面的映射信息：
图四
根据这个映射信息表，文件系
