摘要：设计一种能够在典型嵌入式环境下应用的线性文件系统，为嵌入式系统Flash空间的管理提供一种非常有效的手段。它包装和通用文件系统类似的API接口，设计的实现独立于实时操作系统（RTOS）和具体的Flash典型，可方便移植到不同的嵌入式应用中。

在嵌入式系统中，为了便于对闪存（Flash）空间进行管理，会采用文件的形式来访问Flash。目前，可以购买到的Flash文件系统一般都是兼容DOS的文件系统（Flash File System，FFS），这对需要一个具有复杂的目录层次，并且DDS文件兼容的系统来说是必要的；但是对大多数的嵌入式应用来说，这种文件系统太过奢侈。笔者在参与嵌入式系统项目的时候，设计了一种线性文件系统，它适用于大多数的嵌入式应用对Flash文件系统的需求。

线性文件系统设计基于三个目标：一是提供给应用程序通过文件名而不是物理地址访问系统Flash的能力；二是文件系统的设计独立于实时操作系统（RTOS），这样可以很容易移植到不同的嵌入式应用中；三是设计统一的底层接口，适应不同的Flash类型。本文设计的线性文件系统为典型的嵌入式系统提供了所需的类文件系统能力。需要注意的是，本文件系统不支持复杂的Flash扇区擦写次数均衡算法，没有目录层次，并且和其它的文件系统不兼容。

1 线性文件系统

线性文件系统的设计思路是这样的：文件分为文件头和文件数据区两个部分，每个文件按照顺序存放在Flash中，以单向链表来链接文件。文件的起始部分是文件头，包含文件的属性、指向下一个文件头的指针、文件头和文件数据区的32位循环冗余校验和（CRC32）等。文件头用一个32位的字来表示文件属性，每位表示一种属性，如数据文件或者是可执行文件，是否已删除的文件等，具体可以根据应用的需要来定义文件的属性；文件头和文件数据区维护独立的CRC32校验，使文件系统能更精确检测文件的完整性。文件的起始地址没有特殊需求，分配给文件系统的Flash大小限制了文件的大小。另外，线性文件系统作为嵌入式系统的一个功能模块，它为应用程序提供与标准文件系统类似的API接口，如：read()、write()、open（）、close()、stat()和seek（）等。对于同时在多片Flash的系统而言，每片Flash相当于一个目标，文件都可存储在任何一片中（当然受物理空间限制），但不能跨片存储。

电池备份的RAM来替换空闲扇区，可以增加Flash的整体寿命，但是对那些预算紧张的应用来说太过奢移。

具体的碎片整理过程是，首先建立碎片整理区。①为每个扇区建立2个CRC32表项；第一个CRC32是这个扇区在碎片整理前的CRC值；第二个CRC32值是计算出来的碎片整理后的CRC32值。这些CRC是当碎片整理过程被打断时，用来重新恢复整理用的。②创建碎片整理文件头信息表，每个活动的文件占用一个表项。③计算①和②的CRC值，并保存。①～③的数据保存在图1中的碎片整理记录区。第二步是文件重定位；遍历文件系统的每个扇区，处理重新定位后存储空间和该扇区相覆盖的文件。在每个扇区被重写之前，扇区原来的信息被保存在空闲扇区里。第三步，擦除Flash；遍历未使用的扇区，确认所有的扇区被删除。第四步，完整性检测：对新的文件进行检测，保证所有重定位的文件都是完整的。

3 应用分析

Flash的扇区有最大擦写次数。当前的Flash芯片一般支持10万～100万次的擦除。文件系统的应用各不相同，所以这里不能下结论说采用线性文件系统Flash的寿命会有多长。下面解释文件系统访问Flash的方法。这样用户可以根据应用来判断Flash的预期寿命。

我们所设计的线性文件系统并不进行扇区删除次数均衡，以延长Flash的使用寿命。如果所需要的文件系统频繁修改并需要扇区删除次数均衡，可以购买现成的Flash文件系统。扇区删除均衡算法大大增加了底层实现的复杂性，并且超出本文的讨论范围。一般来说，通过文件系统来管理Flash的需求远大于对Flash扇区擦写次数均衡的需求，特别是现在越来越多的Flash扇区都支持100万次的擦写。

如上面所提到的，文件系统本身提供给编程者的接口API与标准OS提供的接口类似。这可能误导开发者认为文件系统可以看作是一个硬盘，以任意的频率进行读写操作。事实并不是这样，线性文件系统碎片整理同制并没有进行擦写次数均衡，这意味着空闲扇区可能会是最早损坏的Flash扇区。因为在碎片整理过程中，空闲扇区被用作其它所有扇区的暂时存放扇区。例如在设计里，有13个扇区Flash用来作线性文件系统区，有1个扇区作为空闲扇区。假设对于最坏情况的碎片整理（13个扇区都影响到），如果每天进行1次碎片整理，对于100 000次擦写次数的Flash而言，可用期能够超过20年（100 000/13/365=21）。20年是基于每