具体的碎片整理过程是，首先建立碎片整理区。①为每个扇区建立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年是基于每天进行1次碎片整理，并且所有扇区都影响到的情况。碎片整理的频率和整理所影响到的扇区数受应用程序使用文件的限制。用户可以根据文件系统的应用来估算Flash扇区的磨损情况，并作相应的处理。
下面讨论文件系统是如何使用扇区的。Flash扇区仅仅在碎片整理时候才被擦除。当删除文件的时候，只是简单地作一个标识（文件头的一个位）。如果一个存在的文件以写的方式打开，实际的修改步骤是，删除原有的文件，并在当前文件系统的最后一个文件之后重写该文件。最后，这个过程会使文件系统的Flash空间被耗尽，这要就需要运行碎片整理程序。碎片整理程序会使已被删除文件所占用的空间被清除，所有活动的文件在Flash中的位置以连续的方式存放。每个扇区的整理过程是，扇区被拷贝到空闲扇区作备份，然后原来的扇区被删除，计算出该扇区在文件整理后的内容，写入扇区，之后删除空闲扇区的备份。文件系统从头到尾每个扇区重复这样作。在碎片整理时，如果一个扇区不需要进行碎片整理，碎片整理程序就不会动这个扇区因此，受碎片整理程序影响的扇区数目依赖于当前被文件系统占用的Flash扇区数和被删除文件在Flash中的位置。
在一个典型的嵌入式应用里，文件系统中的可执行文件本身就是应用程序。可执行文件一般是最大的文件，也是最不可能经常改变的文件。这意味着执行文件所占用的空间是相对固定的，将会减少空闲扇区因为碎片整理而进行的擦写次数。另外一方面，如果有任何文件需要定期改动，碎片整理将会更加频繁运行。
结语
本文所设计的线性文件系统已经成功应用在笔者参加的嵌入式系统的产品，并且在实践中证明是一种比较有效的管理Flash的方式。当然，线性文件系统不是解决所有嵌入式应用管理Flash空间问题的答案，但是它对于那些不能判断是否要购买现成的Flash文件系统的项目提供了一个非常有用的选择方案。有关线性文件系统实现的C源代码，可以通过E-Mail:WuYJ@263.net.cn直接与笔者联系。
