摘要:CF卡是一种基于Flash技术的容量大、携带方便的存储介质,已在嵌入式系统等领域得到广泛的应用;但是,有限的擦写次数极大地限制了CF卡的使用寿命。TrueFFS通过一系列算法,能够延长CF卡的使用寿命,提高CF卡的使用效率。文章介绍了TrueFFS的原理,在CF卡上实现TrueFFS的方法,并对TrueFFS的性能进行了分析。
关键词:TrueFFS 损耗均衡 闪速存储器 CF卡
闪速存储器最大的一个缺点就是寿命有限。可擦除的次数因芯片厂商而有所不同,一般都在1万~10万次左右。为了延长闪速存储器的寿命,提高使用效率,Msystems公司推出了TrueFFS系统。它为种类繁多的闪速存储器提供了统一的块设备接口,并且具有可重入、线程安全的特点;支持大多数流行的CPU架构,如PowerPC、MIPS、ARM、X86、68K等。
由于个性鲜明的闪速存储器越来越受到嵌入式系统工程师的青睐,业界流行的嵌入式实时操作系统VxWorks已将TrueFFS作为自身的一个可裁减的模块。目前该模块的版本为2.0,支持Intel、AMD、Toshiba、Fujitsu等厂家生产的大多数型号的闪速存储器和Flash卡,用户只需要更改少量代码,甚至可直接调用;但是,该模块对如今风靡的CF卡缺乏支持。
CF卡采用了Flash技术。形象地说,CF卡就是由若干片闪速存储器外加一个管理器组成;但是,CF卡具有携带方便、易于升级、存储量大、抗震性好、兼容性佳等优点。目前,CF卡标准已经达到1.4版本,容量从最早的2MB到现今的1GB。然而,有限的擦写闪数是闪速存储器遗传给CF卡的先天缺陷。本文介绍如何在CF上实现TrueFFS系统,硬件平台以PowerPC处理器(MPC8250,Motorola公司)为CPU,嵌入式操作系统是VxWorks。
1 TrueFFS的结构
TrueFFS本身并不是一个文件系统,需要在TrueFFS之上加载DOS文件系统才能使用,否则毫无意义。TrueFFS屏蔽了下层存储介质的差异,为开发者提供了统一的接口方式。应用程序对存储设备的读写就对像对拥有DOS文件系统的磁碟设备的操作一样。
如图1所示,TrueFFS由1个核心层和3个功能层组成:编译层、MTD层(Memory Technoilogy Driver)、Socket层。
翻译层主要实现TrueFFS和DOS文件系统之间的高级交互功能,管理文件系统和Flash中各物理可擦块的关系,以及TrueFFS中各种智能化处理功能,例如块映射、损耗均衡(wear-leveling)等。目前有三种不同的翻译层模块可供选择。选择哪一种模块要根据使用的Flash介质采用NOR技术、还是NAND技术,或者SSFDC技术而定。
MTD层实现对具体的Flash进行读、写、擦、ID识别、映射等驱动,并设置与Flash密码相关的一些参数。VxWorks的TrueFFS已经包括了支持Intel、AMD、Toshiba等厂商的大多数Flash芯片的MTD层驱动。新的器件需要编写新的MTD层驱动。
Socket层提供了TrueFFS和硬件之间的接口服务,负责电源管理、检测设备插拔、硬件写保护、窗口管理和向系统注册Socket等。
核心层将其它三层有机结合起来,处理全局问题,例如信息量、计时器、碎片回收和其它系统资源等。
我们最关心的是MTD层和Socket层。VxWorks只提供了编译后的二进制形式的核心层和翻译层驱动。在实现TrueFFS应用之间,先介绍一下TrueFFS的原理。
2 TrueFFS原理
2.1 损耗均衡
闪速存储器不能无限次重复使用。它的每个扇区的擦除次数虽然很大,但却有限;因此,随着使用次数的加长,它最终会变成只读状态,所以应该尽最大 可能延长它的寿命。行之有效的方法就是平衡使用所有的存储单元,而不让某一单元过度使用。这种技术被称之为损耗均衡。TrueFFS使用一种基于一张动态维护表的存储器——块映射的翻译系统来实现损耗均衡技术。当块数据被修改、移动或碎片回收后,这张维护表会自动调整。
然而,如果存储在Flash上的一些数据本质上是静态的,就会产生静态文件锁定问题。存储这些静态数据的区域根据不会被轮循使用,其它区域就会被更频繁地使用,这将降低Flash期望的生命值。TrueFFS通过强制转移静态区域的方法成功克服了静态文件锁定问题。因为映射表是动态的,TrueFFS能够以对文件系统不可见的方式转移这些静态数据区域。由于绝对强制损耗均衡方式会对性能产生一些负面影响,所以TrueFFS采取了一种非绝对损耗均衡算法。它保证了所有空间的使用近似平等而不影响性能。
2.2 碎片回收
块数据的修改使得Flash的一些块区域中的数据不再有效,并且这些区域在擦除之前变得不可写。如果没有机制来回收这些区域,Flash很快就会变成只读的状态了。不幸的是由于这些块不可能单独擦除,回收这些块就有些复杂了。单次擦除被限制在一个叫作擦除单元的较大范围内,如对于AMD的Am29LV065D芯片来说是64KB。
TrueFFS使用一种被称为碎片回收的机制来回收那些不再包含有效数据的块。该机制从一个预擦除单元内复制所有的有效数据块到另一个新的被称为转移单元的擦除单元。然后,TrueFFS更新映射表,再擦除这个废旧的预擦除单元。这样,原来的块出现在外界时仍然包含了原来的数据,虽然这些数据现在已经存放在Flash存储器的其它空间。
碎片回收算法会找到并回收与下面标准最吻合的擦除单元:
①废块最多;
②擦除次数最少;
③最静态的区域。
2.3 块分配和关联数据集结
为了提高数据的读取效率,TrueFFS使用一种灵活的空间分配策略:将关联的数据(如由同一个文件的内容组成的多个块)集结到同一个单独擦除单元内的一段连续的区域中。为此,TrueFFS尽量在同一个擦除单元内维持一个由多个物理上连续的自由块组成的存储池。如果这样连续的存储池无法实现,TrueFFS分尽量保证池中的所有块是在同一个擦除单元内。如果连这样的情况也不可能的话,TrueFFS会尽量把块池分配到一个拥有最多可用空间的擦除单元内。
这种集结关联数据的途径有几个好处。首先,如果TrueFFS必须从一个小的存储窗口来访问Flash,那么这样集结了的关联数据可以减少调用映射物理块到该窗口的次数,加快了文件继续访问速度。其次,这种策略可以减少碎片的产生。这是因为删除一个文件可以释放掉更容易回收的完整块,意味着碎片回收会变得更快。另外,它可以使属于静态文件的多个块存放在同一地址,这样当损耗均稀算法决定移动静态区域时,转移这些块就变得更加容易了。
2.4 错误恢复
向Flash写数据有时可能会出错,比如在响应文件系统写请求时、碎片回收期间甚至在TrueFFS格式化或擦除Flash时。在这些情况下,TrueFFS能够从错误中恢复过来;但在新数据第一次写入Flash时如果出错就会丢失这些数据。然而,TrueFFS非常仔细地保证所有已经存放在Flash上的数据是可恢复的,甚至能够避免用户由于不耐烦或好奇而猛地拔出Flash卡而可能造成的灾难性后果。
TrueFFS健壮的关键是它使用了一种“先写后擦”的策略。当更新Flash一个扇区的数据时,只有在更新操作完成并且新存储的数据校验成功后,先前的数据才会被允许擦掉。这样的结果是数据扇区不能处于部分写状态。操作成功的话新扇区的数据有效,否则老扇区的数据有效。很明显,这样有利于用户已经写到Flash上的数据的稳定性。
3 编程
TrueFFS的编程主要在MTD层和Socket层。首先必须在当前VxWorks生成目录的配置文件(config.h)中定义:INCLUDE_TFFS(包含TrueFFS系统)、和INCLUDE_TFFS_SHOW(包含TrueFFS系统的显示函数)。
3.1 翻译层
翻译层根据Flash的实现技术来选择。设计中选用了SST公司的型号为SST49CF064的CF卡,64MB容量。它是基于NAND的Flash技术,所以在文件中定义INCLUDE_TL_NFTL;如果是NOR技术,则定义INCLUDE_TL_FTL。
3.2 MTD层
文件cfCardMTD.c实现了MTD层的功能。在本设计中,MTD层主要实现4个函数:读、写、擦除和ID识别。
ID识别函数根据读取设备的ID号来选择与当前设备匹配的MTD驱动。识别函数中指定了针对当前设备的一些参数以及基本操作函数,并赋给一个叫FLFlash的数据结构。
FLStatus cfMTDIdentify(FLFlash*pVol);
数据结构中的主要参数赋值如下:
pVol->type=CF_ID; /*器件ID号*/
pVol->erasableBlockSize=512;/*可擦除的最小单元是512B*/
pVol->chipSize=0x4000000;/*器件容量为64MB*/
pVol-write=cfWriteRoutine;/*写函数*/
pVol->read=cfReadRoutine;/*读函数*/
pVol->rease=cfEraseRoutine;/*擦函数*/
pVol->map=cfMap;/*将CF卡的一段区域映射到内存空间*/
CF卡的读函数比Flash的读函数繁琐。它和写一样,必须根据一定的算法来读取数据,而Flash只需要直接从地址中读数据。但是,CF卡的擦函数非常简单,直接返回就可以了。因为CF卡可以直接调用写命令写入数据,CF卡本身能够自动完成擦除操作。CfMap函数将CF卡的一段区域映射到存储空间,一般为4KB。因为CF卡的40MB地址空间并不映射到系统的存储空间中,映射可以加快系统访问CF卡的速度,而Flash的地址空间,所以Flash的MTD驱动中的该函数可以为空。
最后,识别函数必须在MTD驱动表单mtdTable[]中注册:
#ifdef INCLUDE_MTD_CFCARD
cfMTDIdentify,
#endif
并增加函数声明:extern FLStatus cfMTDIdentify (FLFlash vol).
3.3 Socket层
文件sysTffs.c实现了Socket层的功能。sysTffsInit()函数是主函数,调用Socket注册函数cfSocketRegister(),初始化Socket数据结构FLSocket。
LOCAL void cfSocketRegister (void){
FLSocket vol=flSocketOf(noOfDrives);
tffsSocket[noOfDrives]=“F”/*Socket名称*/
vol.window.baseAddress=CF_BASE_ADRS>>12;/*窗口的基地址*/
vol.cardDetected=cfCardDetected;/*检测CF卡是否存在的函数*/
vol.VccOn=cfVccOn;/*CF卡上电函数*/
vol.VccOff=cfVccOff;/*CF卡继电函数*/
vol.initSocket=cfInifSocket;/*CF卡初始化函数*/
vol.setMappingContext=cfSetMappingContext;/*CF卡映射函数*/
vol.getAndClearCardChangeIndicator=cfGetAndClearCard ChangeIndicator;/*设置改变函数*/
vol.writeProtected=cfWriteProtected;/*CF卡写保护判断函数*/
noOfDrives++;
}
其中,映射窗口的基地址以4KB为单位。TrueFFS系统每100ms调用CF卡检测函数,判断CF卡是否存在。CF卡上电函数和断电函数主要用于节省系统功耗,当CF卡出于闲置状态时,TrueFFS就关闭CF卡的电源。CF卡初始化函数负责访问CF卡之前的所有前期工作。如果插入CF卡型号改变了,cfGetAndClearCard ChangeIndicator函数就会及时向TrueFFS系统报告。sysTffs.c中需要实现上述的所有函数。大部分情况下,开发人员不必关心FLSocket数据结构,只关心它的成员函数。一旦这些成员函数实现了,开发人员不能直接调用它们,它们被TrueFFS系统自动调用。
4 实现与性能分析
完成TrueFFS的编写之后,经过编译链接,如果一切正确,VxWorks运行时会调用tffsDrv()函数自动初始化TrueFFS系统,包括建立互斥信号量、全局变量和用来管理TrueFFS的数据结构,注册Socket驱动程序。当TrueFFS需要和底层具体硬件打交道时,它使用设备号(0~4)作为索引来查找它的FLSocket结构,然后用相应结构中的函数来控制它的硬件接口。成功完成Socket注册之后,用户就可以调用tffsDevCreate()创建一个TrueFFS块设备,调用tffsDevFormat格式化设备,再调用dosFsDevInit()函数加载DOS文件系统。之后,用户就可以像使用磁碟设备一样使用了CF卡了,如调用open、read、write、close、creat等文件操作函数。
TrueFFS的简单测试方法可以从主机复制一个文件到CF卡,再将这个文件从CF卡复制到主机,然后比较原文件和最后文件的区别。用户也可以调用tffsShow()或tffsShowAll()来查看TrueFFS的创建情况。
TrueFFS可以极大地延长Flash设备的寿命。一般CF卡可以擦写10万次,如果不使用TrueFFS系统,寿命就非常短。例如,在CF卡上实现一个FAT16格式的DOS文件系统,簇的大小是2KB,如果要向CF卡中写入一个8MB的文件,共占用4K个簇,出于可靠性考虑,每写一个簇,FAT表就更新一次,写一个8MB的文件,FAT表需要更新4096次;而FAT表一直位于某个固定扇区中,所以8MB的文件最多只能更新25次,一个每天需要备份的文件,那么CF卡的寿命只有25天。这种应用方式使CF卡寿命与其容量无关,其它绝大部分可用扇区白白浪费。
采用了TrueFFS系统之后 ,因为损耗均衡算法不允许FAT表固定在某个扇区中,损耗平均分配给所有物理扇区。期望的CF卡寿命可以用下列公式计算:
期望寿命=(容量×总擦写次数×0.75)/每天写入字节数
其中,0.75表示文件系统和TrueFFS管理结构的额外消耗系数。如果同样每天备份一个8MB文件,那么期望寿命=(64MB×100 000×0.75)/8MB=600000(天)(约1643年)。
可见,TrueFFS惊人地延长了Flash器件的寿命。VxWorks自带的TrueFFS驱动器覆盖了业界大部分主流Flash芯片,考虑了各种芯片的不同擦写算法,效率较低。对于产时性要求苛刻的系统,开发人员应该按照所用的Flash器件有针对性地制作了TrueFFS驱动器。目前某些CF卡本身实现了一定程度的损耗均衡算法,但是没有TrueFFS那么高效。