英创信息技术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及频繁文件操作的应用中,这种缺陷就可能对设备产生威胁。但我们也可以有充分的手段彻底规避这样的风险,同时又不降低系统的整体性能。

打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分