1 Yaffs文件系统结构
1.1 简介
1.1.1 应用场合
Yaffs（Yet Another Flash File System）文件系统是专门针对NAND闪存设计的嵌入式文件系统，目前有YAFFS和YAFFS2两个版本，两个版本的主要区别之一在于YAFFS2能够更好的支持大容量的NAND FLASH芯片。
Yaffs文件系统有些类似于JFFS/JFFS2文件系统，与之不同的是JFFS1/2文件系统最初是针对NOR FLASH的应用场合设计的，而NOR FLASH和NAND FLASH本质上有较大的区别，所以尽管JFFS1/2 文件系统也能应用于NAND FLASH，但由于它在内存占用和启动时间方面针对NOR的特性做了一些取舍，所以对NAND来说通常并不是最优的方案。
1.1.2 NOR和NAND的比较
基本上NOR比较适合存储程序代码，其容量一般较小（比如小于32MB），价格较高，而NAND容量可达1GB以上，价格也相对便宜，适合存储数据。一般来说，128MB以下容量NAND FLASH 芯片的一页大小为528字节，用来存放数据，另外每一页还有16字节的备用空间（SpareData,OOB），用来存储ECC校验/坏块标志等信息，再由若干页组成一个块，通常一块为32页16K。
与NOR相比，NAND不是完全可靠的，每块芯片出厂时都有一定比例的坏块存在，对数据的存取不是使用地址映射而是通过寄存器的操作，串行存取数据。
1.2 Yaffs文件系统数据在NAND上的存储方式
Yaffs对文件系统上的所有内容（比如正常文件，目录，链接，设备文件等等）都统一当作文件来处理，每个文件都有一个页面专门存放文件头，文件头保存了文件的模式、所有者id、组id、长度、文件名、Parent Object ID等信息。因为需要在一页内放下这些内容，所以对文件名的长度，符号链接对象的路径名等长度都有限制。
前面说到对于NAND FLASH上的每一页数据，都有额外的空间用来存储附加信息，通常NAND驱动只使用了这些空间的一部分，Yaffs正是利用了这部分空间中剩余的部分来存储文件系统相关的内容。以512+16B为一个PAGE的NAND FLASH芯片为例,Yaffs文件系统数据的存储布局如下所示：
|
0..511 |
数据区域 |
|
512..515 |
YAFFS TAG |
|
516 |
Data status byte |
|
517 |
Block status byte 坏块标志位 |
|
518..519 |
YAFFS TAG |
|
520..522 |
后256字节数据的ECC校验结果 |
|
523..524 |
YAFFS TAG |
|
525..527 |
前256字节数据的ECC校验结果 |
可以看到在这里YAFFS一共使用了8个BYTE用来存放文件系统相关的信息（yaffs_Tags）。这8个Byte的具体使用情况按顺序如下：
|
Bits |
Content |
|
20 |
ChunkID，该page在一个文件内的索引号，所以文件大小被限制在2^20 PAGE 即512Mb |
|
2 |
2 bits serial number |
|
10 |
ByteCount 该page内的有效字节数 |
|
18 |
ObjectID 对象ID号，用来唯一标示一个文件 |
|
12 |
Ecc, Yaffs_Tags本身的ECC校验和 |
|
2 |
Unused |
其中Serial Number在文件系统创建时都为0，以后每次写具有同一ObjectID和ChunkID的page的时候都加一，因为Yaffs在更新一个PAGE的时候总是在一个新的物理Page上写入数据，再将原先的物理Page删除，所以该serial number可以在断电等特殊情况下，当新的page已经写入但老的page还没有被删除的时候用来识别正确的Page，保证数据的正确性。
ObjectID号为18bit，所以文件的总数限制在256K即26万个左右。
最后以上这些是针对Yaffs1而言，对于Yaffs2因为针对chunk size大于1k的NAND FLASH，在Tags各分量及总体尺寸上都做了修改，以便更快更好的处理大容量的NAND FLASH芯片。由于Tag尺寸的增大，在512+16B类型的NAND FLASH上就一个Trunk对应一个page的情况，目前就无法使用Yaffs2文件系统了。
由于文件系统的基本组织信息保存在页面的备份空间中，因此，在文件系统加载时只需要扫描各个页面的备份空间，即可建立起整个文件系统的结构，而不需要像JFFS1/2 那样扫描整个介质，从而大大加快了文件系统的加载速度。
1.3 yaffs文件系统在内存中的组织方式
1.3.1 SupperBlock
操作文件系统的第一步自然是取得SuperBlock了，Yaffs文件系统本身在NAND Flash上并不存在所谓的SuperBlock块，完全是在文件系统mount的过程中由read_super函数填充的，不过有意思的一点是，由于物理上没有存储superblock块，所以NAND Flash上的yaffs文件系统本身没有存储filesystem的魔数（MagicNum），在内存中superblock里的s_magic参数也是直接赋值的，所以存储在NAND FLASH上的任何文件系统都能被当作yaffs文件系统mount上来，只是数据都会被当作错误数据放在lost+found目录中，不知道这算不算yaffs文件系统的一个bug。
通常一个具体的文件系统在VFS的Super_block结构中除了通用的数据外，还有自己专用的数据，Yaffs文件系统的专用数据是一个yaffs_DeviceStruct结构，主要用来存储一些相关软硬件配置信息，相关函数指针和统计信息等。
1.3.2 文件在内存中的组织方式
在mount过程执行read_super的过程中，Yaffs文件系统还需要将文件系统的目录结构在内存中建立起来。由于没有super块，所以需要扫描Yaffs分区，根据从OOB中读取出的yaffs_tags信息判断出是文件头page还是数据page。再根据文件头page中的内容以及数据page中的ObjectID/ChunkID/serial Number等信息在内存中为每个文件（Object）建立一个对应的yaffs_object对象。
在yaffs_object结构中，主要包含了：
Ø 如修改时间，用户ID，组ID等文件属性；
Ø 用作yaffs文件系统维护用的各种标记位如脏（dirty）标记，删除标记等等；
Ø 用作组织结构的，如指向父目录的Parent指针，指向同级目录中其他对象链表的siblings双向链表头结构
此外根据Object类型的不同（目录，文件，链接），对应于某一具体类型的Object，在Yaffs_object中还有其各自专有的数据内容
Ø 普通文件：文件尺寸，用于快速查找文件数据块的yaffs_Tnode 树的指针等
Ø 目录：目录项内容双向链表头（children）
Ø 链接：softlink的alias，hardlink对应的ObjectID
除了对应于存储在NAND FLASH上的object而建立起来的yaffs_object以外，在read_super执行过程中还会建立一些虚拟对象（Fake Object），这些Fake Object在NAND FLASH上没有对应的物理实体，比如在建立文件目录结构的最初，yaffs会建立四个虚拟目录（Fake Directory）：rootDir, unlinkedDir, deleteDir, lostNfoundDir分别用作根目录，unlinked对象挂接的目录，delete对象挂接的目录，无效或零时数据块挂接的目录。
通过创建这些yaffs_object，yaffs文件系统就能够将存储在NAND FLASH上数据系统的组织起来，在内存中维护一个完整的文件系统结构。
2 Yaffs文件系统集成及应用相关
2.1 系统移植
这里所谓移植，就是在特定的软硬件环境里编译出yaffs文件系统模块了。目前最新的yaffs版本的代码里主要是按照2.6内核的方式写的Kconfig和Makefile，对于2.4内核来说，改起来也很简单，基本上，只需要：
Ø 在内核中建立YAFFS目录fs/yaffs，并把下载的YAFFS代码复制到该目录下面。
Ø 参考yaffs代码中的Kconfig文件，按照2.4内核的风格修改你自己的Config.in文件，使得可以配置YAFFS。
Ø 修改fs/makefile，加入yaffs目录
Ø 按照2.4内核的风格修改YAFFS目录中的Makefile文件。
只是在配置YAFFS的时候需要注意一点，即使你的NAND FLASH是512+16B的，不需要使用YAFFS2，也需要将对2k page的NAND FLASH的支持这一项选上，否则编译无法通过（因为部分代码没有用CONFIG宏包起来），不知道这是不是我下载的这个版本的个别现象，还是对Makefile还需要进一步的修改。
此外就是最好把Lets Yaffs do its own ECC选上，理由后面会说，其他选项就无所谓了，主要是对性能的调整，看着选吧，按推荐配置好了，比如Turn off debug chunk erase check，这一项，我试验的结果选上后平均可以提高20-30%左右的擦写速度。
2.2 Yaffs文件系统的制作和使用
2.2.1 通过Yaffs Image文件制作yaffs文件系统
Yaffs源代码包的utils目录下包含了mkyaffsimage/mkyaffs2image的代码，简单的修改一下Makefile里的内核路径就能编译出mkyaffsimage/mkyaffs2image工具。
运行mkyaffsimage dir imagename可以制作出yaffs1文件系统的镜像。
但是，需要注意的是，制作出来的yaffs image文件与通常的文件系统的image文件不同，因为在image文件里除了以512字节为单位的一个page的data数据外，同时紧跟在后还包括了16字节为单位的NAND备份数据区（OOB）的数据。所以实际上是以528个字节为单位的。就是因为包含了这额外的16字节/page的数据，所以基本上常规办法如dd，或者通常的下载其它类型image的工具就无法正常下载yaffs image了，需要修改你所使用的下载工具的代码，使得它能将yaffs image中的这些额外数据也写入NAND FLASH OOB中。
这里还有一点需要注意的是，通过mkyaffsimage制做出来的image其OOB中也包含它自己计算的ECC校验数据，其校验算法有可能和MTD NAND驱动的校验算法不同，如果在内核中由MTD来处理ECC，会造成MTD认为所有的page都校验错误。所以，这也是我前面说最好把Lets Yaffs do its own ECC选上的原因，同时，要把MTD NAND驱动中的ECC校验关闭。
2.2.2 其它方式制作yaffs文件系统
如果不考虑产线批量下载的话，也可以通过mount拷贝的方式准备yaffs文件系统。用flash_eraseall将NAND FLASH分区擦除，然后做为yaffs分区直接mount上来，将文件系统的内容拷贝上去就可以了。这可能是在真正的NAND FLASH上试验yaffs文件系统最简单的方式了。
2.2.3 没有相应的NAND设备时如何测试yaffs文件系统
没有相应的NAND FLASH设备包含两种情况：
Ø 硬件上没有NAND FLASH，开发板上没有或者想在主机环境中测试yaffs文件系统
Ø 没有合适的page size的NAND FLASH芯片，比如板上NAND FLASH芯片为512+16的格式，但是想要试验Yaffs2文件系统。
Yaffs提供了两种用来在这种情况下测试yaffs文件系统的途径。
2.2.3.1 Nandemul
Yaffs source包里包含了mtdemul目录，Yaffs2中该目录下的文件主要是Nandemul2k.c用来模拟2K page size的NAND FLASH。在Yaffs中则是Nandemul.c用来模拟512字节page size的NAND FLASH。
稍微修改一下Makeflie将编译出来的模块插入内核，将在/dev/mtd /dev/mtdblock目录下创建一个新的MTD设备。然后就可以将该设备当作一个物理的MTD NAND设备分区进行相关的操作，可以在上面创建yaffs文件系统，mount umount等等。这种方法不仅适用于yaffs文件系统，同样也适用于其它可用于NAND设备的文件系统。
2.2.3.2 Yaffsram
根据yaffs 官方文档的描述，通过mount –t yaffsram none /mountpoint 可以在内存中建立一个yaffs分区，这有些类似于ramfs。不过，在试验最新版本的Yaffs2文件系统时，该功能并不可用，只有Yaffs1文件系统的代码包里包含了相关的代码。
