CRAMFS简介
CRAMFS文件系统是专门针对闪存设计的只读压缩的文件系统,其容量上限为256M,采用zlib压缩,文件系统类型可以是EXT2或EXT3.
如果使用RAMDISK方式来使用文件系统,那么在系统运行之后,首先得把flash上的映像文件全部解压到ram中,构造ramdisk环境,才可以运行程序,但有一个致命的弱点,在正常情下,同样的代码不仅在flash占用了空间,而且还在ram中占用极大的空间,这违背了嵌入式中节省资源的原则.
cramfs文件系统并不需要一次性地将文件系统中的所有内容解压到ram中,而只是是系统需要访问某个位置的数据时,马上计算出该数据在cramfs中的位置,将其解压到ram中,然后通过内存访问来获取数据,cramfs中的解压缩之后的内存中的数据存放位置都是由cramfs文件系统本身来管理,用户并不需要实现过程,因此增加了透明度,给开发人员节约了时间.
cramfs拥有以下一些特性:
采用实时解压缩方式,但解压缩的时候有延迟。
cramfs的数据都是经过处理、打包的,对其进先写操作有一定困难。所以cramfs不支持写操作,这个特性刚好适合嵌入式应用中使用Flash存储文件系统的场合。
在cramfs中,文件最大不能超过16MB。
支持组标识(gid),但是mkcramfs只将gid的低8位保存下来,因此只有这8位是有效的。
支持硬链接。但是cramfs并没有完全处理好,硬链接的文件属性中,链接数仍然为1.
cramfs的目录中,没有“.”和“..”这两项。因此,cramfs中的目录的链接数通常也仅有一个。
cramfs中,不会保存文件的时间戳(timestamps)信息。当然,正在使用的文件由于inode保存在内存中,因此其时间可以暂时地变更为最新时间,但是不会保存到cramfs文件系统中去。
当前版本的cramfs只支持PAGE_CACHE_SIZE为4096的内核。因此,如果发现cramfs不能正常读写的时候,可以检查一下内核的参数设置。
YAFFS简介
YAFFS是第一个专门为NAND Flash存储器设计的嵌入式文件系统,适用于大容量的存储设备;并且是在GPL(General Public License)协议下发布的,可在其网站免费获得源代码。
YAFFS中,文件是以固定大小的数据块进行存储的,块的大小可以是512字节、1 024字节或者2 048字节。这种实现依赖于它能够将一个数据块头和每个数据块关联起来。每个文件(包括目录)都有一个数据块头与之相对应,数据块头中保存了ECC(Error Correction Code)和文件系统的组织信息,用于错误检测和坏块处理。充分考虑了NAND Flash的特点,YAFFS把这个数据块头存储在Flash的16字节备用空间中。当文件系统被挂载时,只须扫描存储器的备用空间就能将文件系统信息读入内存,并且驻留在内存中,不仅加快了文件系统的加载速度,也提高了文件的访问速度,但是增加了内存的消耗。
为了在节省内存的同时提高文件数据块的查找速度,YAFFS利用更高效的映射结构把文件位置映射到物理位置。文件的数据段被组织成树型结构,这个树型结构具有32字节的节点,每个内部节点都包括8个指向其他节点的指针,叶节点包括16个2字节的指向物理地址的指针。YAFFS在文件进行改写时总是先写入新的数据块,然后将旧的数据块从文件中删除。这样即使在修改文件时意外掉电,丢失的也只是这一次修改数据的最小写入单位,从而实现了掉电保护,保证了数据完整性。
结合贪心算法的高效性和随机选择的平均性,YAFFS实现了兼顾损耗平均和减小系统开销的目的。当满足特定的小概率条件时,就会尝试随机选择一个可回收的页面;而在其他情况下,则使用贪心算法来回收最“脏”的块[2]。
YAFFS文件系统是按层次结构设计的,分成以下4部分: yaffs_guts.c,文件系统的主要算法,这部分代码完全是用可移植的C语言编写的;yaffs_fs.c,Linux VFS层的接口;NAND 接口,yaffs_guts 和NAND 内存访问函数之间的包装层,例如调用Linux mtd 层或者RAM模拟层;可移植函数,服务的包装函数。最重要的一点是,为了获得更好的移植性,YAFFS提供直接调用的模式,这才使得我们有机会来实现YAFFS文件系统在C51系统上的移植。
CRAMFS & YAFFS
cramfs这种只读的压缩格式,linux内核是直接支持的,而yaffs必须要自己来打补丁才能让内核支持,在yaffs2的目录内执行sh patch-ker.sh c $KERNEL 就可以让内核支持yaffs格式了。至于根文件系统个人觉得cramfs要好些,即省空间又是只读的,对于产品来说安全性稍高一点点。
首先需你有两个分区,一个cramfs和一个yaffs,这个要通过bootloader来实现。当根文件系统设置为cramfs后,修改一下初始化的脚本liunxrc,在里面加上一句mount /dev/mtdblockX /my 其中X为的yaffs分区number,即可实现两种分区共存。TE2440的板子出厂时/dev/mtdblock/3是cramfs格式,/dev/mtdblock/4是yaffs的,内核启动后用mount /dev/mtdblock/4 /root之后,就可以操纵那一块yaffs的空间了。
这里还有一个小问题,/dev/mtdblock/2是内核的分区,我在mount /dev/mtdblock/2 /tmp和umount/tmp之后,有save exit: isCheckpointed 0的提示,重新启动时提示Dabort kernel就死了,使用串口下载内核到RAM里启动,再mount /dev/mtdblock/2 /root(/root为空)发现原来/tmp下的文件夹出现在了/root下,也就是/dev/mtdblock/2里。所以板子内核这块貌似只读的分区,只要mount出来一样是可以破坏它的,无意间的发现不知道是内核的小缺陷,还是我没有明白真实意义,有待查明。
CRAMFS文件系统是专门针对闪存设计的只读压缩的文件系统,其容量上限为256M,采用zlib压缩,文件系统类型可以是EXT2或EXT3.
如果使用RAMDISK方式来使用文件系统,那么在系统运行之后,首先得把flash上的映像文件全部解压到ram中,构造ramdisk环境,才可以运行程序,但有一个致命的弱点,在正常情下,同样的代码不仅在flash占用了空间,而且还在ram中占用极大的空间,这违背了嵌入式中节省资源的原则.
cramfs文件系统并不需要一次性地将文件系统中的所有内容解压到ram中,而只是是系统需要访问某个位置的数据时,马上计算出该数据在cramfs中的位置,将其解压到ram中,然后通过内存访问来获取数据,cramfs中的解压缩之后的内存中的数据存放位置都是由cramfs文件系统本身来管理,用户并不需要实现过程,因此增加了透明度,给开发人员节约了时间.
cramfs拥有以下一些特性:
采用实时解压缩方式,但解压缩的时候有延迟。
cramfs的数据都是经过处理、打包的,对其进先写操作有一定困难。所以cramfs不支持写操作,这个特性刚好适合嵌入式应用中使用Flash存储文件系统的场合。
在cramfs中,文件最大不能超过16MB。
支持组标识(gid),但是mkcramfs只将gid的低8位保存下来,因此只有这8位是有效的。
支持硬链接。但是cramfs并没有完全处理好,硬链接的文件属性中,链接数仍然为1.
cramfs的目录中,没有“.”和“..”这两项。因此,cramfs中的目录的链接数通常也仅有一个。
cramfs中,不会保存文件的时间戳(timestamps)信息。当然,正在使用的文件由于inode保存在内存中,因此其时间可以暂时地变更为最新时间,但是不会保存到cramfs文件系统中去。
当前版本的cramfs只支持PAGE_CACHE_SIZE为4096的内核。因此,如果发现cramfs不能正常读写的时候,可以检查一下内核的参数设置。
YAFFS简介
YAFFS是第一个专门为NAND Flash存储器设计的嵌入式文件系统,适用于大容量的存储设备;并且是在GPL(General Public License)协议下发布的,可在其网站免费获得源代码。
YAFFS中,文件是以固定大小的数据块进行存储的,块的大小可以是512字节、1 024字节或者2 048字节。这种实现依赖于它能够将一个数据块头和每个数据块关联起来。每个文件(包括目录)都有一个数据块头与之相对应,数据块头中保存了ECC(Error Correction Code)和文件系统的组织信息,用于错误检测和坏块处理。充分考虑了NAND Flash的特点,YAFFS把这个数据块头存储在Flash的16字节备用空间中。当文件系统被挂载时,只须扫描存储器的备用空间就能将文件系统信息读入内存,并且驻留在内存中,不仅加快了文件系统的加载速度,也提高了文件的访问速度,但是增加了内存的消耗。
为了在节省内存的同时提高文件数据块的查找速度,YAFFS利用更高效的映射结构把文件位置映射到物理位置。文件的数据段被组织成树型结构,这个树型结构具有32字节的节点,每个内部节点都包括8个指向其他节点的指针,叶节点包括16个2字节的指向物理地址的指针。YAFFS在文件进行改写时总是先写入新的数据块,然后将旧的数据块从文件中删除。这样即使在修改文件时意外掉电,丢失的也只是这一次修改数据的最小写入单位,从而实现了掉电保护,保证了数据完整性。
结合贪心算法的高效性和随机选择的平均性,YAFFS实现了兼顾损耗平均和减小系统开销的目的。当满足特定的小概率条件时,就会尝试随机选择一个可回收的页面;而在其他情况下,则使用贪心算法来回收最“脏”的块[2]。
YAFFS文件系统是按层次结构设计的,分成以下4部分: yaffs_guts.c,文件系统的主要算法,这部分代码完全是用可移植的C语言编写的;yaffs_fs.c,Linux VFS层的接口;NAND 接口,yaffs_guts 和NAND 内存访问函数之间的包装层,例如调用Linux mtd 层或者RAM模拟层;可移植函数,服务的包装函数。最重要的一点是,为了获得更好的移植性,YAFFS提供直接调用的模式,这才使得我们有机会来实现YAFFS文件系统在C51系统上的移植。
CRAMFS & YAFFS
cramfs这种只读的压缩格式,linux内核是直接支持的,而yaffs必须要自己来打补丁才能让内核支持,在yaffs2的目录内执行sh patch-ker.sh c $KERNEL 就可以让内核支持yaffs格式了。至于根文件系统个人觉得cramfs要好些,即省空间又是只读的,对于产品来说安全性稍高一点点。
首先需你有两个分区,一个cramfs和一个yaffs,这个要通过bootloader来实现。当根文件系统设置为cramfs后,修改一下初始化的脚本liunxrc,在里面加上一句mount /dev/mtdblockX /my 其中X为的yaffs分区number,即可实现两种分区共存。TE2440的板子出厂时/dev/mtdblock/3是cramfs格式,/dev/mtdblock/4是yaffs的,内核启动后用mount /dev/mtdblock/4 /root之后,就可以操纵那一块yaffs的空间了。
这里还有一个小问题,/dev/mtdblock/2是内核的分区,我在mount /dev/mtdblock/2 /tmp和umount/tmp之后,有save exit: isCheckpointed 0的提示,重新启动时提示Dabort kernel就死了,使用串口下载内核到RAM里启动,再mount /dev/mtdblock/2 /root(/root为空)发现原来/tmp下的文件夹出现在了/root下,也就是/dev/mtdblock/2里。所以板子内核这块貌似只读的分区,只要mount出来一样是可以破坏它的,无意间的发现不知道是内核的小缺陷,还是我没有明白真实意义,有待查明。
这样,不希望用户修改的文件都放在cramfs分区下,供用户随意修改的放在yaffs下就可以有效利用Flash,实现两种分区共存了。当然前提是你的内核必须支持。
转 http://cngeeks.net/forum.php?mod=viewthread&tid=479