英创信息技术Windows CE5.0文件系统分析

由于工控设备渐进变化的基本特征，Windows CE5.0仍然被大量的应用在当前的嵌入式主板中。英创公司的EM9160、EM9360等型号的工控主板也都继续预装CE5.0操作系统。由于CE5.0文件系统是基于微软的Windows95/98内核的FAT文件系统，当基于FAT的CE5.0文件系统应用到NAND Flash器件上时，NandFlash的以扇区为单元的读写方式、以及块为单元的擦除方式，有可能让CE5.0文件系统产生很大的NandFlash存储单元整理工作量。大规模的NandFlash整理将消耗很大一部分CPU时间，如果此时应用程序又有很重的数据存储的任务，在非常极端情况下，有可能导致CE5.0文件系统的FAT表损坏。本文则是针对这种情况，提出两种解决方法。

目前我们通常使用的NandFlash的逻辑结构有两种，一种是扇区（Sector）大小为512字节，一个块（Block）包括32个扇区，被称为小扇区结构；另一种是扇区大小为2048字节（即2KB），一个块包括64个扇区，这种结构的NandFlash通常称为大扇区。可以容易算出，文件系统对NandFlash的整理，大扇区的工作量是小扇区的8倍。因此在同样的运行条件下，大扇区结构的NandFlash对文件系统的负载就高得多。为了确定CE5.0文件系统的这个潜在问题，我们选用了EM9160的精简版，其基本配置为16-bit数据宽度 32MB内存+128MB大扇区NandFlash作为实验平台。采用16-bit数据宽度是让CPU的处理能力至少降低一倍，而128MB大扇区NandFlash为文件系统只提供了768个Block，从而更容易触发文件系统的后台整理进程。

我们的基本测试程序（即应用程序）是以低效率的小文件（一个文件大小不超过512字节，试验文件大小为180字节）为单位，256个小文件存放在一个目录中，总共256个目录循环写。同时在测试程序中启动一个定时线程，定时时间为5s – 100s之间的随机数，定时到时该线程强制重启系统，这样对文件系统施加一个随机重启的冲击。为了观察CPU的基本工作情况，测试程序主线程每2s从调试串口输出CPU负载率等系统信息。基本的试验情况如下：

1、CPU常规负载率在65%水平，当系统进行NandFlash整理时，负载率会上升至95%的水平，且最长时间会持续近10s。

2、经过连续24小时试验，大约有3%的主板的FAT表会损坏，导致系统启动失败。

在测试程序中采用的文件写方式是最直接的流程：

// CreateFile -> WriteFile -> CloseHandle

当所写的文件已经存在于NandFlash时，CE5.0的TFAT文件系统会以某种方式保留原文件，这样若在写文件过程中遇到系统重启，重启后系统还能恢复原来的文件。但这样做的代价是CE5.0文件系统会启动后台线程并行来处理这些老文件。经过大量的试验分析，我们相信正是这种类似的并行操作NandFlash的机制，可能存在某种缺陷，导致在极端情况下FAT的损坏。

根据上面的分析，我们的第一种处理方法，就是在应用程序中增加删除同名文件，再进行常规文件写流程，即：

// 第一种方法：

// DeleteFile -> CreateFile -> WriteFile -> CloseHandle

就可把原来需要后台并行处理的任务变成了应用程序线程顺序执行，从而大幅度减少多个线程并行操作NandFlash的情况。修改后的试验表明，FAT损坏率至少降低一个数量级以上，在目前的试验规模上已完全不能检测到FAT损坏的情况。

第一种方法是通过应用程序调整，来降低NandFlash操作的并行度，从而避免触发CE5.0文件的缺陷显现。但第一种方法还不能完全消除对NandFlash的并行操作，因为后台的整理总是存在的。由此产生第二种方法，就是通过监视CPU负载率，一旦CPU负载超过某个阈值，应用线程就暂停文件写操作，这样就能主动避免应用程序与后台并行操作NandFlash。其基本流程变成：

// 第二种方法：
bRet = g_pNandMonitor->EnterNandAccess(dwTimeout)； // 获取NAND访问权
// 若bRet = TRUE，进入正常NAND操作：
// DeleteFile -> CreateFile -> WriteFile -> CloseHandle
g_pNandMonitor->LeaveNandAccess()； // 归还NAND访问权

在上述流程中，使用了我们构造的一个CPU负载率监控类NandFlashMonitor，当CPU负载率超过指定阈值时，应用线程调用EnterNandAccess函数，将导致应用线程阻塞（挂起）直至超时或CPU负载率低于指定阈值。采用CPU负载率监测手段后，可以看到在后台整理时段，CPU负载率从原来的95%的水平下降到85%的水平，说明在这个时段的应用程序的NandFlash确实是停掉了，同时也说明在这个时段分配给应用程序的资源实际是很少的，所以写文件的效率是很低的。采用延时写的方法，是不会对总体性能影响的。需要检测类NandFlashMonitor代码的客户，可邮件向英创技术支持索取。

总之，通过试验表明，CE5.0的TFAT文件系统对NandFlash管理策略上确实存在某种缺陷，在大扇区NandFlash及频繁文件操作的应用中，这种缺陷就可能对设备产生威胁。但我们也可以有充分的手段彻底规避这样的风险，同时又不降低系统的整体性能。