JFFS2 是将节点信息保存在内存中

 

Flash上日志型文件系统的资料，了解到传统的基于闪存转换层（FLT）的文件系统存在的主要问题：
1. 效率低。因为每次都要把要修改的数据所在擦写块放入内存，产生了许多不必要的读操作；写入时，要将原来的擦写块擦除，然后再将内存中修改的数据写入该擦写块。这样就造成了数据带宽的严重浪费。
2. 降低了Flash的寿命。因为有大量无用的擦写动作，使得许多不需要擦除的块被擦除重写，这导致了整个Flash使用寿命的降低。
3. 没有提供磨损平衡，也会降低Flash的寿命。因为只要一个擦写块坏了，整块Flash也就不能用了，而那些频繁修改的块将会比其它块更快地成为坏块。
4. 不安全。如果在擦写过程中突然 掉电 ，那么整个擦写块的数据将可能丢失。

日志型文件系统(LogFS)就是为解决以上问题而产生的，它将对文件的修改描述成日志，从而减少对Flash的擦写。只有当擦写请求超过一个擦写块的边界时，文件系统才会对Flash进行擦写。这种更新方式也叫out-of-place。
JFFS2 就是Flash上应用最广的一个日志结构的文件系统。它提供的垃圾回收机制，使得我们不需要马上对擦写越界的块进行擦写，而只需要将其设置一个标志，标明为脏块。当可用的块数不足时，垃圾回收机制才开始回收这些节点。同时，由于JFFS2 基于日志结构，在意外掉电 后仍然可以保持数据的完整性，而不会丢失数据。

然而，JFFS2 仍然有其缺点，这也是人们提出JFFS3的原因。
因为挂载时需要扫描整块Flash，来确定节点的合法性以及建立必要的数据结构，这使得JFFS2 挂载时间比较长。
又由于JFFS2 是将节点信息保存在内存中的，使得它所占用的内存量和节点数目成正比。
另外，由于JFFS2 是通过随机方式来实现磨损平衡的，它不能保证磨损平衡的确定性。

 

 

 

日志式文件系统在强调数据完整性的企业级服务器中有着重要的需求，是文件系统发展的方向。日志式文件系统的思想来自于如Oracle等大型数据库。数据库操作往往是由多个相关的、相互依赖的子操作组成，任何一个子操作的失败都意味着整个操作的无效性，对数据库数据的任何修改都要回复到操作以前的状态。日志式文件系统采用了类似的技术。  

　　在分区中保存有一个日志记录文件，文件系统写操作首先是对记录文件进行操作，若整个写操作由于某种原因(如系统掉电)而中断，则在下次系统启动时就会读日志记录文件的内容来恢复没有完成的写操作。而这个过程一般只需要几秒钟到几分钟，而不是ext2文件系统的fsck那样在大型服务器情况下可能需要几个小时来完成扫描。 

我所说的 损坏的数据并不是指 flash 上的坏块， jiffs 是有坏块管理的，或者说它能够避开坏块，不去使用坏块。
所谓的坏块，其实就是不能完全擦除干净的块，其实还是能写入数据的。
所谓损坏的数据， 比如你现在的情况， 刚擦除，还没写入就掉电了， 这种就算是了。
另外还有一些，比如硬件不够稳定，导致写入的数据不完整， 或者驱动写得不够健壮，
都有可能引起数据不完整的情况出现， 而这些数据就是 jiffs 不认可的数据，但是 flash 硬件并没有问题，
或者说这个块并不是坏块。



是不是如果一个分区里只要有一个坏block，jffs2就mount不上呢？如果不是这样的话，那么导致
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
坏的数据可能导致 jiffs2 mount 不起来， 但是 flash 上的坏块却不会导致 mount 不起来。
jiffs2 mount 不上的原因只能去读代码了， 就是要看哪些情况对程序来书哦是不合法的。
yaffs2的代码我阅读过， jiff2 的没仔细研究过，所以不好说。。。

至于 flash IC 自己会标识坏块， 这个说法也是错误的。
标识坏块要靠软件去做，或者说驱动去 修改每个 block 的 第一个 page 的 oob 信息。 具体可以参考 nand flash 的规范。
硬件自己可干不了这事， 具体可参考 内核中的 nand_base.c 和 nand_bbt.c