YAFFS2源码分析
- 格式:pdf
- 大小:2.12 MB
- 文档页数:63
OK6410、2.6.36内核移植,dm9000 驱动移植,详细!分类:嵌入式学习Linux学习2012-04-27 00:54 3004人阅读评论(7) 收藏举报interfaceccompressionresourcesstructtable还是先来吐槽:本来我是在上一个星期的周末已经把Linux2.6.34.11 的驱动已经成功的移植到,OK6410 的开发板上的,并且能够启动主机上的NFS 根文件系统,可是我在周一的时候,开始学习LCD 的驱动程序,在修改内核文件的时候,有几处错误修改,将原来自己做的2.6.34.11 的内核源码搞的乱七八糟的,在这里还是自己在修改内核的时候没有提注重注释,并且没有记录下来自己的操作步骤,以至于我没办法,恢复2.6.34 的内核,所以也就只能重新先开始最基础的内核移植了。
这次我选择的是2.6.36.2 的内核,谁知到一开始移植就出现一大堆问题。
在这里我不得不说,飞凌开发人员对内核修改的代码,管理真的是太扯了,自己在注销任何一个设备是没有一点点注释,就把这个设备原有的线性地址分配给其它设备了,让我让我们这些菜鸟干看着一大堆的报错信息顶个什么用,真的是伤不起。
好了不乱扯了,现在开始记录。
我的开发环境是:VMware Ubuntu 10.10 。
OK6410 A版256M+2G 的开发板。
主机系统:XP。
Uboot:飞凌提供的Uboot。
参考内核:飞凌提供的Forlinx 的2.6.36.2 内核操作步骤以下./ 均代表你的内核根目录1、修改./Makefile191 ARCH ?=arm // 指定cpu类型,arm后面不要有空格,要不然编译是会提醒ARCH 不能为一个目录192 CROSS_COMPILE ?=/usr/local/arm/4.2.2-eabi/usr/bin/arm-linux- // 指定交叉编译器的路径,按照你自己的进行指定路径2、先来说说nand flash 的驱动涉及到的文件:MTD 通用nand flash 驱动程序位置:./drivers/mtd/nand/.nand_base.cNAND Flash 的platform 设备信息: ./drivers/mtd/nand/s3c_nand.c有了上面的依赖驱动依赖程序、接下来修改./arch/arm/mach-s3c64xx/mach-smdk6410.c 1) nandflash 驱动,修改方法加载头文件[cpp]view plaincopyprint?1.#include <linux/mtd/mtd.h>2.#include <linux/mtd/partitions.h>3.#include <plat/nand.h> //这些头文件放在./arch/arm/plat-samsung/include/ 下面添加nand 结构体[cpp]view plaincopyprint?1.// add by acanoe first2.extern void s3c64xx_reserve_bootmem(void); //add by acanoe3.4.5.struct mtd_partition ok6410_nand_part[] = {6. {7. .name = "Bootloader",8. .offset = 0,9. .size = (1 * SZ_1M),10. .mask_flags = MTD_CAP_NANDFLASH,11. },12. {13. .name = "Kernel",14. .offset = (1 * SZ_1M),15. .size = (5*SZ_1M) ,16. .mask_flags = MTD_CAP_NANDFLASH,17. },18. {19. .name = "User",20. .offset = (6 * SZ_1M),21. .size = (120*SZ_1M) ,22. },23. {24. .name = "File System",25. .offset = MTDPART_OFS_APPEND,26. .size = MTDPART_SIZ_FULL,27. }28.};29.30.31.static struct s3c2410_nand_set ok6410_nand_sets[] = {32. [0] = {33. .name = "nand",34. .nr_chips = 1,35. .nr_partitions = ARRAY_SIZE(ok6410_nand_part),36. .partitions = ok6410_nand_part,37. },38.};39.40.41.static struct s3c2410_platform_nand ok6410_nand_info = {42. .tacls = 25,43. .twrph0 = 55,44. .twrph1 = 40,45. .nr_sets = ARRAY_SIZE(ok6410_nand_sets),46. .sets = ok6410_nand_sets,47.};48.//add by acanoe first修改 smdk6410_devices[] __initdata = {对照这个结构体将那些进行修改,注意 by acanoe 的语句为修改重点。
深⼊理解yaffs2⽂件系统(⼀)深⼊理解yaffs2⽂件系统(⼀)1、Flash⽂件系统1.1、背景已经有多种flash⽂件系统(FFSs)或flash块驱动(在之上运⾏⼀个常规的FS),同时都有优点或缺点。
Flash存储器有⾮常多的限制,这⾥就不⼀⼀列举了。
已经有各种⽅法解决这些限制,以提供⼀个⽂件系统。
必须认识到,“flash”,包括NOR和NAND,各⾃有不同的限制。
很容易被专业术语“flash”误导,误以为⽤于NorFlash的⽅法也⽴即适⽤于NandFlash。
Nand块驱动⼀般采⽤FAT16作为⽂件系统,但不够健壮,也不够贴近Flash的特性。
这些块驱动通过⼀个“本地--物理”的映射层来仿真可写的、类似于磁盘扇区的块。
当使⽤FAT16时,这些⽂件系统⼯作的相当好,它们内存消耗⼩,代码尺⼨也很⼩。
但就像所有基于FAT 的系统⼀样,它们很容易损坏(如,丢失簇)。
其他的途径则是设计整个⽂件系统,不是基于块驱动,⽽且是flash友好的,这允许更多的余地来解决上述所提到的问题。
当前有两个linux⽂件系统能⾮常好的⽀持NorFLash,那就是JFFS以及它的升级版本JFFS2。
这两者都提供⽇志机制,⼤⼤的提升了健壮性,这也是嵌⼊式系统特别重要的⼀个特性。
不幸的是,它们在RAM消耗和启动时间⽅⾯都不是很好。
JFFS在flash中的每⼀个journalling⽇志节点,需要⼀个基于RAM的jffs_node结构,每⼀个节点为48字节。
JFFS2做了⼀个⼤改进,通过剪裁相关的结构体(jffs2_raw_node_ref)⽽减少到16字节。
即使如此,在512字节页⼤⼩128M的NandFlash,按平均节点⼤⼩来算,也需要250000字节约4M⼤⼩。
JFFS和JFFS2在启动时,需要扫描整个flash阵列来查找journaling节点,并决定⽂件结构。
由于NAND容量⼤、慢、连续访问、需要ECC校验,这些特性将导致不可接受的、很长的启动时间。
基于Linux的大容量Yaffs文件系统性能优化与实现刘翠玲;时兴;孙晓荣;梁明全【摘要】针对Yaffs文件系统应用在大容量存储设备时所产生挂载速度慢的问题,提出一种新的改进方法,并在Yaffs2文件系统中进行了实现。
通过在Yaffs2文件系统中增加适当的偏移量,使得在扫描挂载文件系统时减少了不必要的扫描时间,从而加快了挂载的速度。
在最新的Yaffs2文件系统当中,依据该方法修改Yaffs2源代码,同时,在Linux系统上加入了对改进后文件系统的支持。
对改进前后的性能进行分析和实验,表明了该方法的可行性。
%AimingattheproblemofslowmountspeedofYaffsfilesystemoccurredwh entobeappliedinstoragedeviceswithlarge capacity,we propose a new improved method,and implement it in Yaffs2 file system.By adding appropriate offset in Yaffss file system,the unnecessary scanning time is reduced when scanning the mounting file system,thereby the mounting speed is accelerated.In latest Yaffs2 file system,we modify the source code of Yaffs2.Meanwhile,we add the support to the modified Yaffs file systemin the Linux system,and analyse the performance before and after the modification.Experiments demonstrate the feasibility of the method.【期刊名称】《计算机应用与软件》【年(卷),期】2014(000)009【总页数】3页(P37-39)【关键词】Yaffs;文件系统;Linux;Flash【作者】刘翠玲;时兴;孙晓荣;梁明全【作者单位】北京工商大学计算机与信息工程学院北京 100048;北京工商大学计算机与信息工程学院北京 100048;北京工商大学计算机与信息工程学院北京100048;北京工商大学计算机与信息工程学院北京 100048【正文语种】中文【中图分类】TP3150 引言在科技高速发展的今天,尤其是以安卓系统为基础的一系列电子产品不断的发展,智能手机,平板电脑,智能电视,数码相机等等的一系列产品都离不开文件系统的支持。
基于YAFFS2文件系统的分区管理对载荷数据存储效率的研究WU Can-qiang;RUI Ye;PAN Dong-mei【摘要】为了引入嵌入式文件系统以解决卫星载荷数据管理难的问题,同时针对新研文件系统可靠性和功能完整性缺乏验证等缺点,本文选用YAFFS2文件系统作为优化基础.然而由于在星栽环境下YAFFS2文件系统的类日志型结构存在对多载荷/多任务数据管理粒度粗、数据存储效率较低等问题,本文提出在YAFFS2文件系统中引入分区管理功能.通过改进YAFFS2文件系统数据结构、设计并实现分区内管理机制和分区间管理机制,实现对多载荷/任务数据的隔离管理,同时提高对复杂数据的检索效率.实验结果表明,分区YAFFS2文件系统在实现对不同文件数据的读写操作时,其读写速度稳定优于原YAFFS2文件系统.【期刊名称】《电子设计工程》【年(卷),期】2018(026)023【总页数】6页(P42-47)【关键词】YAFFS2文件系统;分区管理;载荷数据;存储效率【作者】WU Can-qiang;RUI Ye;PAN Dong-mei【作者单位】【正文语种】中文【中图分类】TP3如今我国航天技术不断提高,卫星应用需求也随之扩大,其存储的载荷数据种类、数据量逐渐增加,数据存储管理难度日益加大[1]。
虽然星载数据存储器经传统的基于FPGA的方式设计后将读写方式由最初以字节为单位线性编址的流读写方式发展为基于文件分配表的文件读写方式[2],但是为了解决Flash存储器应用存在的不覆盖写、磨损均衡问题并实现文件系统的完整功能,使用嵌入式文件系统管理星载数据存储器在未来星载数据存储技术的发展上显得尤为必要。
目前常用的嵌入式文件系统主要有两种:一种是JFFS/JFFS2文件系统[3-4],其专门针对NOR FLASH存储介质设计,因此用于NAND FLASH存储介质上效果不佳;另外一种则是YAFFS/YAFFS2文件系统[5-6],其专门针对NAND FLASH存储介质的特性设计,具有崩溃恢复、坏块管理、损耗均衡、垃圾回收及错误探测/错误更正(EDC/ECC)的FLASH文件系统必须具备的功能。
Yaffs2文件系统移植到mini2440现在大部分开发板都可以支持yaffs2 文件系统,它是专门针对嵌入式设备,特别是使用nand flash作为存储器的嵌入式设备而创建的一种文件系统,早先的yaffs仅支持小页(512byte/page)的nand flash,使用yaffs2 就可以支持大页的nand flash。
所谓的根文件系统,就是创建各个目录,并且在里面创建各种文件,比如在/bin,/sbin/目录下存放各种可执行的程序,在/etc目录下存放配置文件,在/lib目录下存放库文件,下面就开始文件系统的移植。
一、准备工作1.Yaffs2源代码的获取在bbb:///node/346可以下载到最新的yaffs2 源代码,如果使用git工具,在命令行输入:就可以下载到yaffs2的源代码,到当前目录下。
2.下载Busybox-1.13.3可以从bbb:///downloads/下载Busybox-1.13.3。
3.下载Yaffs2的整理工具可以到友善之臂的网站下载,mkyaffs2image.tgz,其中解压出来有两个可执行的文件,一个是针对小页的,一个是针对NandFlash大页的,其名字为mkyaffs2image-128M,一开始在这里犯了错误,我的NandFlash是128MB的,可以按照网上用的是mkyaffs2image文件,所以老是出来假坏块的提示,仔细一分析,NandFlash不可能一下子出来这么多的坏块,而且我用他们公司提供的根文件系统却没有任何的问题,所以问题处在了整理Yaffs2的工具上面。
因为这两种大小NandFlash的ECC校验是不一样的,也就是spare区的大小是不一样的,造成了ECC校验出错。
4.链接库整理根文件系统时,要使用到链接库,这里直接使用友善之臂根文件系统中的链接库。
从网站下载root_qtopia.tgz。
使用lib目录下的链接库。
5.给内核打上YAffs2补丁然后进入yaffs2源代码目录执行:#cd yaffs2#./patch-ker.sh c /opt/mini2440/linux-2.6.33.3此时进入linux-2.6.32.2/fs目录,可以看到已经多了一个yaffs2目录。
yaffs2分析(原)文件系统的重要作用就是对文件或者文件夹的数据进行相应的管理,无论是文件数据还是文件夹里面的内容数据在文件系统看来就是一个个元数据(metadata)。
文件系统就是实现这些元数据的相应管理。
由于yaffs2 是一个相对比较简单的文件系统,下面通过yaffs的启动过程看看yaffs文件元数据的组织。
由于Yaffs是基于nand flash 的,由于nand所特有的一些特性,所以yaffs就有了一些自身文件系统所特有的一些特性。
如文件的结构信息是保存在spare 里面的,无论是文件夹数据还是文件数据,都是保存到spare数据的。
typedef struct {unsigned sequenceNumber;unsigned objectId;unsigned chunkId;unsigned byteCount;} yaffs_PackedTags2TagsPart;保存在spare 里面的yaffs2结构如上。
在yaffs启动时候,如果checkpoint没有响应的保存掉电时的结构的话,就需要进行一下全盘的扫描,其中的扫描主要是在yaffs_scan里面完成的,文件系统结构的创建就是主要在这个scan的过程中实现的。
static int yaffs_Scan(yaffs_Device *dev){1 首先就是要对全盘的block 块进行相应的扫描,主要就是扫描出坏的块/* Scan all the blocks to determine their state */bi = dev->blockInfo;for (blk = dev->internalStartBlock; blk <= dev->internalEndBlock; blk++) {}2 对于坏的块进行相应的标记玩之后,就是逐个对block 里面每一个page进行扫描,并建立相应的结构/* For each chunk in each block that needs scanning....*/for (c = 0; !alloc_failed && c < dev->param.nChunksPerBlock &&state == YAFFS_BLOCK_STATE_NEEDS_SCANNING; c++) {if (!tags.chunkUsed) {如果是一个未被使用的page的话由系统进行回收。
Yaffs2根文件系统制作环境:交叉编译环境:4.3.3 (天嵌科技提供,存放路径/opt/EmbedSky/4.3.3)开发平台:TQ24401,编译busybox获取busybox源码busybox-1.17.2.tar (/downloads/)置于目录/opt/embed下#tar jxvf busybox-1.17.2.tar.bz2#cd busybox-1.17.2#vim Makefile将164行改为CROSS_COMPILE = arm-linux- 将190行改为ARCH = arm 保存推出进入配置菜单#make menuconfig 采用默认配置保存推出#make#make install在busybox-1.17.2的根目录下出现了一个_install目录在该目录下又有三个目录文件bin sbin usr 和一个链接文件 linuxrc 。
2,创建根文件系统必要的目录回到/opt/embed目录下创建根文件系统必要的目录#mkdir root_fs#cd root_fs将刚才生成的三个目录bin sbin usr和一个链接文件linuxrc考到目录root_fs下#cp -rf ../busybox-1.17.2/_install/* ./#mkdir dev etc home lib mnt opt proc root sys tmp var创建几个必要的二级目录#mkdir usr/lib usr/share#mkdir etc/rc.d#mkdir var/lib var/lock var/run var/tmp3,创建必要文件(1), 获取库文件 (我的交叉编译工具链放在目录 /opt/EmbedSky/下的)#cp -rf /opt/EmbedSky/4.3.3/arm-none-linux-gn?i/libc/armv4t/lib/* so* lib -a(2),将主机 etc 目录下的passwd、group、shadow文件拷贝到 root_fs/etc 目录下#cp -f /etc/passwd /etc/group /etc/shadow etc将目录/opt/embed/busybox-1.17.2/examples/bootfloppy/etc下的所有文件拷贝到root_fs/etc下。
yaffs2⽂件系统⼯具mkyaffs2imageyaffs2⽂件系统是针对nandflash的⽂件系统,其制作⼯具为mkyaffs2image。
⼀、差异不同nand容量,⼯具不⼀样。
⾸先使⽤的是mkyaffs2image,编译⽣成根⽂件系统的镜像之后,下载到板⼦上,启动的时候报错,错误代码这⾥没有上传。
问题出在⼯具使⽤的不正确,查看⼯具⽬录下,发现有mkyaffs2image-128M⼯具,于是在⽹上查阅了⾸先采⽤的mkyaffs2image和mkyaffs2image-128M的区别,发现这对不同的板载nand flash容量,使⽤不同的⼯具制作根⽂件系统。
查看了⾃⼰使⽤的友善之臂板⼦上使⽤的nand flash是256M的,于是果断使⽤mkyaffs2image-128M⼯具制作根⽂件系统。
因为mkyaffs2image-128M针对128M或者更⼤的容量。
⼆、编译If you want to use GIT directly from the command line then public read-only access is available, using the (bash) command:git clone git:///yaffs2mkyaffs2image是在yaffs⽂件系统的utils⽬录下,只把其中的chunkSize spareSize 与 pagesPerBlock⼏个变量,按照nand_flash中的改⼀下就可以⽤。
// Adjust these to match your NAND LAYOUT://#define chunkSize 8192//#define spareSize 232#define chunkSize 4096//#define spareSize 218#define spareSize 128#define pagesPerBlock 128三、使⽤1、验证是否成功可直接在终端下输⼊:mkyaffs2imagemkyaffs2image: image building tool for YAFFS2 built Jul 92009usage: mkyaffs2image dir image_file [convert]dir the directory tree to be convertedimage_file the output file to hold the image'convert' produce a big-endian image from a little-endian machine注意核对convert的⼤⼩端。
Yaffs 文件系统分析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正是利用了这部分空间中剩余的部分来存储文件系统相关的内容。
yaffs2源代码分析(一)yaffs2源代码情景分析作者:斑点Email: byeyear@1.前言略。
2.yaffs文件系统简介按理说这里应该出现一些诸如“yaffs是一种适合于NAND Flash的文件系统XXXXX”之类的字眼,不过考虑到网络上关于yaffs/yaffs2的介绍已经多如牛毛,所以同上,略。
3.本文内容组织本文将模仿《linux内核源代码情景分析》一书,以情景分析的方式对yaffs2文件系统的源代码进行分析。
首先将分析几组底层函数,如存储空间的分配和释放等;其次分析文件逻辑地址映射;然后是垃圾收集机制;接下来……Sorry,本人还没想好。
:-)4.说明因为yaffs2貌似还在持续更新中,所以本文所列代码可能和读者手中的代码不完全一致。
另外,本文读者应熟悉C语言,熟悉NAND Flash 的基本概念(如block和page)。
Ok,步入正题。
首先分析存储空间的分配。
5.NAND Flash存储空间分配和释放我们知道,NAND Flash的基本擦除单位是Block,而基本写入单位是page。
yaffs2在分配存储空间的时候是以page为单位的,不过在yaffs2中把基本存储单位称为chunk,和page是一样的大小,在大多数情况下和page是一个意思。
在下文中我们使用chunk这个词,以保持和yaffs2的源代码一致。
我们先看存储空间的分配(在yaffs_guts.c中。
这个文件也是yaffs2文件系统的核心部分):static int yaffs_AllocateChunk(yaffs_Device * dev, int useReserve,yaffs_BlockInfo **blockUsedPtr){int retVal;yaffs_BlockInfo *bi;if (dev->allocationBlock < 0) {/* Get next block to allocate off */dev->allocationBlock = yaffs_FindBlockForAllocation(dev);dev->allocationPage = 0;}函数有三个参数,dev是yaffs_Device结构的指针,yaffs2用这个结构来记录一个NAND器件的属性(如block和page的大小)和系统运行过程中的一些统计值(如器件中可用chunk的总数),还用这个结构维护着一组NAND操作函数(如读、写、删除)的指针。
嵌入式Linux下大容量Nand FLASH的YAFFS2文件系统构建查启鹏;姚国良;张萌【期刊名称】《现代电子技术》【年(卷),期】2007(30)18【摘要】YAFFS2文件系统支持页大小为2 kB的大容量Nand FLASH和一些具有严格写入时序如零重写要求的Nand FLASH,是嵌入式系统中实现对Nand FLASH管理的理想方案.重点分析了YAFFS2相对于YAFFS1所做的两点重要改进,即垃圾回收策略和checkdata的引入,并介绍了Nand FLASH的硬件接口设计和MTD驱动编写方法,给出了Intel Xscale PXA255、Linux 2.4.19平台下,在页大小为2 kB的大容量Nand FLASH上构建YAFFS2的方法和过程.【总页数】4页(P55-58)【作者】查启鹏;姚国良;张萌【作者单位】东南大学,国家专用集成电路系统工程中心,江苏,南京,210096;东南大学,国家专用集成电路系统工程中心,江苏,南京,210096;东南大学,国家专用集成电路系统工程中心,江苏,南京,210096【正文语种】中文【中图分类】TP311【相关文献】1.超大容量NAND Flash文件系统-YAFFS2在Linux下的实现 [J], 龙亚春;黄璞;吴胜2.Yaffs2文件系统中对NAND Flash磨损均衡的改进 [J], 温朝建;严华3.在Linux中实现大容量NAND Flash的YAFFS2文件系统 [J], 展中华;杜刚4.嵌入式Linux下NAND flash上根文件系统的构建 [J], 程建5.Yaffs2文件系统中NAND Flash块选择策略的改进 [J], 杨智;严华因版权原因,仅展示原文概要,查看原文内容请购买。
1 概述YAFFS (Yet Another Flash File System )文件系统是专门针对NAND flash 设计的嵌入式文件系统,目前有YAFFS 和Y AFFS2两个版本,两个版本的主要区别之一在于Y AFFS2 能够更好的支持大容量的NAND flash 芯片。
YAFFS 文件系统有些类似于JFFS/JFFS2文件系统,与之不同的是JFFS/JFFS2文件系统最初是针对NOR flash 的应用场合设计的,而NORflash 和NAND flash 本质上有较大的区别,尽管JFFS/JFFS2文件系统也能应用于NANDflash ,但由于它在内存占用和启动时间方面针对NOR 的特性做了一些取舍,所以YAFFS2对NAND flash 来说通常才是最优的选择方案。
2 相关概念分析YAFFS2之前,把NAND flash 相关概念介绍下:NAND flash 由块(block)组成,块又由页(page)构成,擦除时以块为单位,读写时以页为单位,页又包含数据区和空闲区(OOB,Out-Of-Band),而Page 在YAFFS2中被称为Chunk ,其中的数据区用来存放实际的数据,OOB 用来存放附加信息实现NAND flash 的管理。
以T8000 AXMPFUA 单板使用的NANDflash 为例,每块Block: 128 pages ,每页Page: (8K + 448) bytes ,数据区为8K ,OOB 为448bytes ,如图1所示:Plane :4096blocks128 pages(8K+448)bytes图1 NAND flash 物理结构3 数据结构struct yaffs_dev 是YAFFS2文件系统最核心的数据结构,表示Y AFFS2文件系统的超级块,它建立了整个文件系统的层次结构,并衔接VFS 层和MTD 层,与struct super_block 、struct mtd_info 的关系如图2所示:图2 yaffs_dev 与super_block 、mtd_info 层次关系下面围绕struct yaffs_dev 这个最核心的数据结构开始,分段介绍它的含义,进而引出其他重要的数据结构:■param :存储文件系统重要的一些参数,以及与MTD 层的接口函数□inband_tags :标志位,默认为0,即采用OOB (out of band )方式存储tags ,可以通过挂载时指定inband-tags选项改变默认值□total_bytes_per_chunk:每个chunk总的字节数□chunks_per_block:每个block总的chunk数□spare_bytes_per_chunk:每个chunk包含OOB块的字节数□start_block:第一个可以使用的block□end_block:最后一个可以使用的block□n_reserved_blocks:为GC保留的block阈值□n_caches:缓冲区的个数,YAFFS2为减少数据的碎片以及提高性能为每个文件的写入提供了cache□no_tags_ecc:标志位,默认为0,即tags中包括ECC纠错信息,可以通过内核配置改变默认值,CONFIG_YAFFS_DISABLE_TAGS_ECC□is_yaffs2:标志位,默认为0,即Y AFFS,在挂载的过程中会根据识别的mtd->writesize自动转换成YAFFS2□refresh_period:刷新周期,刷新目的主要找出最旧的处于YAFFS_BLOCK_STATE_FULL状态的block,供GC作为gc_block使用□skip_checkpt_rd:标志位,默认为0,支持读取checkpoint,提高挂载速度的一个功能可以通过挂载时指定挂载选项no-checkpoint-read、no-checkpoint修改默认值□skip_checkpt_wr:标志位,默认为0,支持写入checkpoint,提高挂载速度的一个功能可以通过挂载时指定挂载选项no-checkpoint-write、no-checkpoint修改默认值□write_chunk_tags_fn:函数指针,在挂载的文件系统的时候会被初始,NANDflash写入接口函数:param->write_chunk_tags_fn = nandmtd2_write_chunk_tags;□read_chunk_tags_fn:函数指针,在挂载的文件系统的时候会被初始,NANDflash读取接口函数:param->write_chunk_tags_fn = nandmtd2_write_chunk_tags;□erase_fn:函数指针,在挂载的文件系统的时候会被初始,NAND flash擦除block接口函数:param->erase_fn = nandmtd_erase_block;□wide_tnodes_disabled:标志位,默认值为0,采用动态位宽,通过内核配置修改可采用静态位宽CONFIG_YAFFS_DISABLE_WIDE_TNODES■os_context:指向yaffs_linux_context结构指针,该结构存储Y AFFS2运行环境,如下:□context_list:通过该字段加入到yaffs_context_list全局链表中□dev:指向Y AFFS2文件系统超级块的指针□super:指向VFS层超级块的指针□bg_thread:Y AFFS2后台垃圾回收线程的指针□bg_running:启动和停止垃圾回收线程的标志位,1:启动,0:停止□gross_lock:互斥锁,保护整个超级块关键字段的互斥访问,粒度比较大□spare_buffer:OOB块的缓冲区□search_contexts:通过该字段把所有Directory Search Context组成链表□yaffs_mtd_put_super:卸载文件系统时被调用来清理super_block□readdir_process:解决使用NFS死锁问题加入的□mount_id:每个NAND flash分区挂载YAFFS2都分配不同的ID号■driver_context:指向mtd_info结构指针,mtd_info是MTD子系统核心的数据结构,主要是对底层硬件驱动进行封装,这里不再介绍■data_bytes_per_chunk:每个chunk总的字节数,和前面提到的total_bytes_per_chunk一样■chunk_grp_bits :采用静态位宽时超过tnode_width宽度之后的位数,采用动态位宽值恒为0■chunk_grp_size:由chunk_grp_bits转化而来的大小■tnode_width:采用静态位宽默认是16,采用动态位宽是由整个NAND flash中chunk数目计算得到■tnode_mask:位宽的mask,主要用于快速获取chunk id号■tnode_size:YAFFS_NTNODES_LEVEL0节点所占用的内存大小,单位:byte■chunk_shift:主要用来计算logical chunk index以及logical chunk offset■chunk_div:作用同chunk_shift,主要用于chunk大小不是2次幂的情况■chunk_mask:作用同chunk_shift,组合起来计算logical chunk offset■is_mounted:标志位,文件系统挂载时被置位Checkpoint是为提高挂载速度而引入的功能,作用同JFFS2的EBS,以空间来换取时间,卸载时通过在NAND flash上保存文件系统超级块快照,挂载时获取快照信息可以快速还原系统的状态。
yaffs2文件系统分析作者:dreamice1.前言略。
2.yaffs文件系统简介按理说这里应该出现一些诸如“yaffs是一种适合于NAND Flash的文件系统XXXXX”之类的字眼,不过考虑到网络上关于yaffs/yaffs2的介绍已经多如牛毛,所以同上,略。
3.本文内容组织本文将模仿《linux内核源代码情景分析》一书,以情景分析的方式对yaffs2文件系统的源代码进行分析。
首先将分析几组底层函数,如存储空间的分配和释放等;其次分析文件逻辑地址映射;然后是垃圾收集机制;接下来……Sorry,本人还没想好。
:-)4.说明因为yaffs2貌似还在持续更新中,所以本文所列代码可能和读者手中的代码不完全一致。
另外,本文读者应熟悉C语言,熟悉NAND Flash的基本概念(如block和page)。
Ok,步入正题。
首先分析存储空间的分配。
5.NAND Flash存储空间分配和释放我们知道,NAND Flash的基本擦除单位是Block,而基本写入单位是page。
yaffs2在分配存储空间的时候是以page为单位的,不过在yaffs2中把基本存储单位称为chunk,和page是一样的大小,在大多数情况下和page是一个意思。
在下文中我们使用chunk这个词,以保持和yaffs2的源代码一致。
我们先看存储空间的分配(在yaffs_guts.c中。
这个文件也是yaffs2文件系统的核心部分):Yaffs2中将该函数更名为yaffs_alloc_chunk。
static int yaffs_AllocateChunk(yaffs_Device * dev, int useReserve,yaffs_BlockInfo **blockUsedPtr){int retVal;yaffs_BlockInfo *bi;if (dev->allocationBlock < 0) {/* Get next block to allocate off */dev->allocationBlock = yaffs_FindBlockForAllocation(dev);dev->allocationPage = 0;}函数有三个参数,dev是yaffs_Device结构的指针,yaffs2用这个结构来记录一个NAND 器件的属性(如block和page的大小)和系统运行过程中的一些统计值(如器件中可用chunk 的总数),还用这个结构维护着一组NAND操作函数(如读、写、删除)的指针。
yaffs2 结构-回复YAFFS2 结构YAFFS2(Yet Another Flash File System 2)是一种用于嵌入式系统的文件系统,特别适用于闪存设备。
它的灵感来自于早期的YAFFS文件系统,但在架构和功能上有所改进。
YAFFS2提供了高效的数据存储和管理方式,使闪存设备在读写操作方面更加稳定和可靠。
YAFFS2的主要结构包括:块(Block)、页(Page)、幸存页(Spare Page)和节点(Node)。
首先,让我们从块开始。
块是YAFFS2中最小的存储单元,它由连续的页组成。
每个块的大小通常为128KB或256KB。
闪存设备的数据存储是以块为单位进行的,这意味着当我们需要存储一个文件或一个数据块时,实际上是将其存储到一个或多个连续的块中。
在每个块中,数据被分为多个页。
每个页的大小通常为2KB或4KB。
这样的设计使得YAFFS2能够更高效地进行读写操作,因为闪存设备的读写速度是以页为单位的。
幸存页是指在每个块中用于存储元数据的页。
元数据包括节点、标志位、CRC等信息。
幸存页的存在使得YAFFS2能够更好地管理闪存设备的使用情况,并使得数据的读写更加可靠。
最后,我们来看一下节点。
节点对于YAFFS2来说非常重要,它是文件系统中的基本单位。
每个节点对应着一个文件或目录。
节点存储了文件的元数据,如文件名、文件大小、文件权限等。
除此之外,节点还存储了指向文件数据在闪存设备上位置的指针。
通过以上的结构,YAFFS2实现了对闪存设备的高效管理和读写。
当我们在闪存设备上创建一个文件时,YAFFS2会为该文件创建一个对应的节点,并将其相关信息存储在该节点中。
当我们写入数据时,YAFFS2将数据分为页,并将这些页存储在连续的块中。
为了保证数据的完整性,YAFFS2还会计算并存储CRC等校验信息。
在读取数据时,YAFFS2会通过节点找到数据的位置,并将其读取到应用程序中。
此外,YAFFS2还具备一些高级功能,如快照(Snapshot)和压缩(Compression)。
1 概述YAFFS (Yet Another Flash File System )文件系统是专门针对NAND flash 设计的嵌入式文件系统,目前有YAFFS 和Y AFFS2两个版本,两个版本的主要区别之一在于Y AFFS2 能够更好的支持大容量的NAND flash 芯片。
YAFFS 文件系统有些类似于JFFS/JFFS2文件系统,与之不同的是JFFS/JFFS2文件系统最初是针对NOR flash 的应用场合设计的,而NORflash 和NAND flash 本质上有较大的区别,尽管JFFS/JFFS2文件系统也能应用于NANDflash ,但由于它在内存占用和启动时间方面针对NOR 的特性做了一些取舍,所以YAFFS2对NAND flash 来说通常才是最优的选择方案。
2 相关概念分析YAFFS2之前,把NAND flash 相关概念介绍下:NAND flash 由块(block)组成,块又由页(page)构成,擦除时以块为单位,读写时以页为单位,页又包含数据区和空闲区(OOB,Out-Of-Band),而Page 在YAFFS2中被称为Chunk ,其中的数据区用来存放实际的数据,OOB 用来存放附加信息实现NAND flash 的管理。
以T8000 AXMPFUA 单板使用的NANDflash 为例,每块Block: 128 pages ,每页Page: (8K + 448) bytes ,数据区为8K ,OOB 为448bytes ,如图1所示:Plane :4096blocks128 pages(8K+448)bytes图1 NAND flash 物理结构3 数据结构struct yaffs_dev 是YAFFS2文件系统最核心的数据结构,表示Y AFFS2文件系统的超级块,它建立了整个文件系统的层次结构,并衔接VFS 层和MTD 层,与struct super_block 、struct mtd_info 的关系如图2所示:图2 yaffs_dev与super_block、mtd_info层次关系下面围绕struct yaffs_dev这个最核心的数据结构开始,分段介绍它的含义,进而引出其他重要的数据结构:■param:存储文件系统重要的一些参数,以及与MTD层的接口函数□inband_tags:标志位,默认为0,即采用OOB(out of band)方式存储tags,可以通过挂载时指定inband-tags选项改变默认值□total_bytes_per_chunk:每个chunk总的字节数□chunks_per_block:每个block总的chunk数□spare_bytes_per_chunk:每个chunk包含OOB块的字节数□start_block:第一个可以使用的block□end_block:最后一个可以使用的block□n_reserved_blocks:为GC保留的block阈值□n_caches:缓冲区的个数,YAFFS2为减少数据的碎片以及提高性能为每个文件的写入提供了cache□no_tags_ecc:标志位,默认为0,即tags中包括ECC纠错信息,可以通过内核配置改变默认值,CONFIG_YAFFS_DISABLE_TAGS_ECC□is_yaffs2:标志位,默认为0,即Y AFFS,在挂载的过程中会根据识别的mtd->writesize自动转换成YAFFS2□refresh_period:刷新周期,刷新目的主要找出最旧的处于YAFFS_BLOCK_STATE_FULL状态的block,供GC作为gc_block使用□skip_checkpt_rd:标志位,默认为0,支持读取checkpoint,提高挂载速度的一个功能可以通过挂载时指定挂载选项no-checkpoint-read、no-checkpoint修改默认值□skip_checkpt_wr:标志位,默认为0,支持写入checkpoint,提高挂载速度的一个功能可以通过挂载时指定挂载选项no-checkpoint-write、no-checkpoint修改默认值□write_chunk_tags_fn:函数指针,在挂载的文件系统的时候会被初始,NANDflash写入接口函数:param->write_chunk_tags_fn = nandmtd2_write_chunk_tags;□read_chunk_tags_fn:函数指针,在挂载的文件系统的时候会被初始,NANDflash读取接口函数:param->write_chunk_tags_fn = nandmtd2_write_chunk_tags;□erase_fn:函数指针,在挂载的文件系统的时候会被初始,NAND flash擦除block接口函数:param->erase_fn = nandmtd_erase_block;□wide_tnodes_disabled:标志位,默认值为0,采用动态位宽,通过内核配置修改可采用静态位宽CONFIG_YAFFS_DISABLE_WIDE_TNODES■os_context:指向yaffs_linux_context结构指针,该结构存储Y AFFS2运行环境,如下:□context_list:通过该字段加入到yaffs_context_list全局链表中□dev:指向Y AFFS2文件系统超级块的指针□super:指向VFS层超级块的指针□bg_thread:Y AFFS2后台垃圾回收线程的指针□bg_running:启动和停止垃圾回收线程的标志位,1:启动,0:停止□gross_lock:互斥锁,保护整个超级块关键字段的互斥访问,粒度比较大□spare_buffer:OOB块的缓冲区□search_contexts:通过该字段把所有Directory Search Context组成链表□yaffs_mtd_put_super:卸载文件系统时被调用来清理super_block□readdir_process:解决使用NFS死锁问题加入的□mount_id:每个NAND flash分区挂载YAFFS2都分配不同的ID号■driver_context:指向mtd_info结构指针,mtd_info是MTD子系统核心的数据结构,主要是对底层硬件驱动进行封装,这里不再介绍■data_bytes_per_chunk:每个chunk总的字节数,和前面提到的total_bytes_per_chunk一样■chunk_grp_bits :采用静态位宽时超过tnode_width宽度之后的位数,采用动态位宽值恒为0■chunk_grp_size:由chunk_grp_bits转化而来的大小■tnode_width:采用静态位宽默认是16,采用动态位宽是由整个NAND flash中chunk数目计算得到■tnode_mask:位宽的mask,主要用于快速获取chunk id号■tnode_size:YAFFS_NTNODES_LEVEL0节点所占用的内存大小,单位:byte■chunk_shift:主要用来计算logical chunk index以及logical chunk offset■chunk_div:作用同chunk_shift,主要用于chunk大小不是2次幂的情况■chunk_mask:作用同chunk_shift,组合起来计算logical chunk offset■is_mounted:标志位,文件系统挂载时被置位Checkpoint是为提高挂载速度而引入的功能,作用同JFFS2的EBS,以空间来换取时间,卸载时通过在NAND flash上保存文件系统超级块快照,挂载时获取快照信息可以快速还原系统的状态。
在Linux中实现大容量 NAND Flash的YAFFS2文件系统作者:展中华杜刚分类:自动化/计算机技术上传者:ZCOM网友摘要分析了嵌入式环境中YAFFS/YAFFS2文件系统的优点,提出YAFFS2不仅支持小容量的NAND flash,对大容量NAND flash更具有优势。
并介绍了YAFFS/YAFFS2文件系统结构。
着重将YAFFS2文件系统在嵌入式Linux系统中的实现过程包括配置、编译以及测试整个完整过程作了详细的论述。
关键词 NAND flash,YAFFS/YAFFS2,嵌入式Linux系统随着嵌入式系统在消费电子、航空航天、汽车电子、医疗保健、网络通信、工业控制等各个领域的广泛应用,嵌入式系统中的数据存储和管理已经成为一个重要的研究课题。
Flash存储器具有存取速度快、容量大、成本低等很多优点,广泛用在嵌入式系统中做存储器件。
目前,市场上Flash存储器主要有NOR(或非)和NAND(与非)两种类型。
针对NOR Flash专门设计的文件系统JFFS/JFFS2(Journaling Flash File System)在嵌入式系统中已得到广泛的应用;随着NAND作为大容量存储介质的广泛应用,专门针对NAND flash特点编写的日志文件系统YAFFS/YAFFS2(Yet Another Flash File System)正逐渐被应用到嵌入式系统中。
一、NAND Flash简介NOR 和NAND是现在市场上两种主要的非易失性闪存技术。
Intel 公司于1988年首先开发出NOR Flash技术,NOR的传输效率较高,在1~4MB的小容量时有明显的成本优势,主要应用在代码存储介质中;NAND则是高密度数据存储的理想解决方案,其容量可达1GB以上,并且写入和擦除速度很快,更适合于数据存储。
NAND Flash的存储单元为页和块,一般来说,该芯片的一页大小为512字节(简称小页),依次分为2个256字节的主数据区,最后是16字节的备用空间;而128MB以上的的芯片使用大小为2K的页(即大页)。
mkyaffs2image工具解析终于可以成功制作页大小为2K + 64 Bytes 的nand flash的image 文件了。
令人兴奋啊:)这两天一直苦于自己制作的yaffs2 image文件系统无法被linux-2.6.29.1内核识别,而使用FriendlyARM的mkyaffs2imag-128M工具就没有这个问题。
一开始便判断是mkyaffs2image工具有问题,没有生成正确格式的yaffs2 image文件,从而导致内核无法识别,并抛出以下错误信息:----------------------------------------------------------------------------------------------------------------……block 155 is badyaffs_read_super: isCheckpointed 0VFS: Mounted root (yaffs filesystem) readonly on device 31:2.Freeing init memory: 164KWarning: unable to open an initial console.Failed to execute /linuxrc. Attempting defaults...Kernel panic - not syncing: No init found. Try passing init= option to kernel.----------------------------------------------------------------------------------------------------------------网上查了很多相关的资料,对2K data + 64bytes spare 的nand flash上yaffs2文件的存储格式并没有较为清晰的说明。
狗拿耗子YAFFS2———狗拿耗子第三篇 1、YAFFS2 的背景 YAFFS2 是 Charles Manning 开发的 NAND Flash 文件系统。
可以从 获得详细 的描述和最新的版本。
关于 Nand Flash 与 Nor Flash 的不同之处,网上有很多文章叙述,这 里不再罗嗦。
反正是在嵌入式系统中,一般是 Nor Flash 存放在 Boot 程序,Nand Flash 作为 正式的存储设备使用。
YAFFS (Yet Another Flash File System) was designed and written by Charles Manning, of Whitecliffs, New Zealand, for the company Aleph One. YAFFS is the first file system that was designed specifically for NAND flash. Yaffs1 is the first version of this file system and works on NAND chips that have 512 byte pages + 16 byte spare (OOB;Out-Of-Band) areas. These older chips also generally allow 2 or 3 write cycles per page, which YAFFS takes advantage of - i.e. dirty pages are marked by writing to a specific spare area byte. Newer NAND flash chips have larger pages, 2048 bytes + 64 bytes spare areas, and stricter write requirements. Each page within a block must be written to in sequential order, and each page must be written only once. YAFFS2 was designed to accommodate these newer chips. YAFFS2 is based on the YAFFS1 source code, with the major difference being that internal structures are not fixed to assume 512 byte sizing, and a block sequence number is placed on each written page. In this way older pages can be logically overwritten without violating the "write once" rule. YAFFS is a robust log-structured file system that holds data integrity as a high priority. A secondary YAFFS goal is high performance. YAFFS will typically outperform most alternatives. It is also designed to be portable and has been used on Linux, WinCE, pSOS, eCOS, ThreadX and various special-purpose OSes. A variant 'YAFFS/Direct' is used in situations where there is no OS, embedded OSes and bootloaders: it has the same core filesystem but simpler interfacing to the OS and NAND flash hardware. The filesystem is licensed both under the GPL and under per-product licences available from Aleph One. YAFFS1 YAFFS has no inherent formatting, an erased flash chip is formatted. It follows the smart media scheme of marking the 5th byte of the spare area for bad blocks, and ignores any blocks where the spare area byte 5 is not 0xFF. To write file data, YAFFS initially writes a whole page (chunk in YAFFS terminology) that describes the file metadata, such as timestamps, name, path, etc. The new file is assigned a unique object ID number; every data chunk within the file will contain this unique object ID within the spare area. YAFFS maintains a tree structure in RAM memory of the physical location of these1狗拿耗子chunks. When a chunk is no longer valid (the file is deleted, or parts of the file are overwritten), YAFFS marks a particular byte in the spare area of the chunk as ‘dirty’. When an entire block (32 pages) is marked as dirty, YAFFS can erase the block and reclaim the space. If free space on the device is low, YAFFS may need to choose a block that has some number of dirty pages and some number of good pages, move the good pages to a new block, mark the old pages as dirty and erase the block. The process of moving good pages & erasing blocks is called Garbage Collection. When a YAFFS system mounts a NAND flash device, it must scan the spare areas of every block to check for valid data, whereby it can then reconstitute the tree data structures. YAFFS2 YAFFS2 is similar in concept to YAFFS1, and shares much the same code; and the YAFFS2 code base supports YAFFS1 data formats through backward compatibility. The main difference is that YAFFS2 needs to jump through significant hoops to meet the "write once" requirement of modern NAND flash. YAFFS2 marks every newly written block with a sequence number that is monotonically increasing. The sequence of the chunks can be inferred from the block sequence number and the chunk offset within the block. Thereby when YAFFS2 scans the flash and detects multiple chunks that have identical ObjectIDs and ChunkNumbers, it can choose which to use by taking the greatest sequence number. For efficiency reasons YAFFS2 also introduces the concept of shrink headers. For example when a file is resized to a smaller size, YAFFS1 will mark all of the affected chunks as dirty - YAFFS2 cannot do this due to the "write once" rule. YAFFS2 instead writes a "shrink header", which indicates that a certain number of pages before that point are invalid. This lets YAFFS2 reconstruct the final state of the filesystem when the system reboots. YAFFS2 uses a more abstract definition of the NAND flash allowing it to be used with a wider variety of flash parts with different geometries, bad block handling rules etc. YAFFS2 now supports "checkpointing" which bypasses normal mount scanning, allowing very fast mount times. Mileage will vary, but mount times of c. 3 seconds for 2 GB have been reported.2狗拿耗子2、chunk 与 block K9F1208 是 64M 的 Nand Flash, 一个 chunk 包含 512byte 的 data area, 16byte 的 spare area, 与 32 个 chunk 构成了一个 block。
狗拿耗子YAFFS2———狗拿耗子第三篇 1、YAFFS2 的背景 YAFFS2 是Charles Manning开发的NAND Flash文件系统。
可以从获得详细的描 述和最新的版本。
关于Nand Flash与Nor Flash的不同之处,网上有很多文章叙述,这里不再 罗嗦。
反正是在嵌入式系统中,一般是Nor Flash存放在Boot程序,Nand Flash作为正式的存 储设备使用。
YAFFS (Yet Another Flash File System) was designed and written by Charles Manning, of Whitecliffs, New Zealand, for the company Aleph One. YAFFS is the first file system that was designed specifically for NAND flash. Yaffs1 is the first version of this file system and works on NAND chips that have 512 byte pages + 16 byte spare (OOB;Out-Of-Band) areas. These older chips also generally allow 2 or 3 write cycles per page, which YAFFS takes advantage of - i.e. dirty pages are marked by writing to a specific spare area byte. Newer NAND flash chips have larger pages, 2048 bytes + 64 bytes spare areas, and stricter write requirements. Each page within a block must be written to in sequential order, and each page must be written only once. YAFFS2 was designed to accommodate these newer chips. YAFFS2 is based on the YAFFS1 source code, with the major difference being that internal structures are not fixed to assume 512 byte sizing, and a block sequence number is placed on each written page. In this way older pages can be logically overwritten without violating the "write once" rule. YAFFS is a robust log-structured file system that holds data integrity as a high priority. A secondary YAFFS goal is high performance. YAFFS will typically outperform most alternatives. It is also designed to be portable and has been used on Linux, WinCE, pSOS, eCOS, ThreadX and various special-purpose OSes. A variant 'YAFFS/Direct' is used in situations where there is no OS, embedded OSes and bootloaders: it has the same core filesystem but simpler interfacing to the OS and NAND flash hardware. The filesystem is licensed both under the GPL and under per-product licences available from Aleph One. YAFFS1 YAFFS has no inherent formatting, an erased flash chip is formatted. It follows the smart media scheme of marking the 5th byte of the spare area for bad blocks, and ignores any blocks where the spare area byte 5 is not 0xFF. To write file data, YAFFS initially writes a whole page (chunk in YAFFS terminology) that describes the file metadata, such as timestamps, name, path, etc. The new file is assigned a unique object ID number; every data chunk within the file will contain this unique object ID within the spare area. YAFFS maintains a tree structure in RAM memory of the physical location of these1狗拿耗子chunks. When a chunk is no longer valid (the file is deleted, or parts of the file are overwritten), YAFFS marks a particular byte in the spare area of the chunk as ‘dirty’. When an entire block (32 pages) is marked as dirty, YAFFS can erase the block and reclaim the space. If free space on the device is low, YAFFS may need to choose a block that has some number of dirty pages and some number of good pages, move the good pages to a new block, mark the old pages as dirty and erase the block. The process of moving good pages & erasing blocks is called Garbage Collection. When a YAFFS system mounts a NAND flash device, it must scan the spare areas of every block to check for valid data, whereby it can then reconstitute the tree data structures. YAFFS2 YAFFS2 is similar in concept to YAFFS1, and shares much the same code; and the YAFFS2 code base supports YAFFS1 data formats through backward compatibility. The main difference is that YAFFS2 needs to jump through significant hoops to meet the "write once" requirement of modern NAND flash. YAFFS2 marks every newly written block with a sequence number that is monotonically increasing. The sequence of the chunks can be inferred from the block sequence number and the chunk offset within the block. Thereby when YAFFS2 scans the flash and detects multiple chunks that have identical ObjectIDs and ChunkNumbers, it can choose which to use by taking the greatest sequence number. For efficiency reasons YAFFS2 also introduces the concept of shrink headers. For example when a file is resized to a smaller size, YAFFS1 will mark all of the affected chunks as dirty - YAFFS2 cannot do this due to the "write once" rule. YAFFS2 instead writes a "shrink header", which indicates that a certain number of pages before that point are invalid. This lets YAFFS2 reconstruct the final state of the filesystem when the system reboots. YAFFS2 uses a more abstract definition of the NAND flash allowing it to be used with a wider variety of flash parts with different geometries, bad block handling rules etc. YAFFS2 now supports "checkpointing" which bypasses normal mount scanning, allowing very fast mount times. Mileage will vary, but mount times of c. 3 seconds for 2 GB have been reported.2狗拿耗子2、chunk 与 block K9F1208 是 64M 的 Nand Flash, 一个 chunk 包含 512byte 的 data area, 16byte 的 spare area, 与 32 个 chunk 构成了一个 block。