英创信息技术WinCE文件系统测试及故障分析简介-电子发烧友网

WINCE文件系统的偶发故障一直是WINCE系统最为棘手的问题，尽管出现故障的几率不高，但对设备的稳定运行造成严重影响。为了保证基于WinCE的嵌入式系统能稳定可靠运行，英创公司对WINCE文件系统进行了长期分析测试，希望能找到有效办法来规避WINCE文件系统故障。本文主要介绍英创在这方面的工作及获得的成果。

先前的工作

过去多年，英创公司陆续做过很多工作改善WINCE文件系统，也取得了一些成效。

1．将文件系统升级成exfat。

2．封装文件读写库，增加缓存空间，使文件读写尽量以整块形式操作。

3．升级数据库版本。

4．实现WINCE5->WINCE6->WEC7的升级。

5．修改NandFlash的ECC校验。

6．将内核注册表类型由HIVE-Based注册表替换为RAM-Based注册表并测试其稳定性。

7．增加文件备份恢复工具BFS。

先前的实验工作

因为文件系统故障极低，使得通过实验程序复现其故障变得很困难。在实验室里通常大量板卡满负荷连续工作1周以上可能才会发现有板卡出现文件系统故障。因为在实验室运行程序始终与用户现场使用存在差异，通过同样CPU负载率完成近似文件读写量，确很难复现文件系统故障。英创公司也采用了很多不同的测试方法进行测试，例如：

数据轮询读写测试

基础的文件读写测试程序，程序满负荷向nandflash写记录文件，写满后删除最早记录继续添加新记录。英创所有板卡均能通过该测试，该实验程序也很难测试出文件系统故障。

数据库读写测试1

程序为C#数据库程序，程序满负荷向SQLCE数据库中不停添加记录，该实验测试了WINCE5,WINCE6的板子，其中WINCE5的板子有测试出文件系统故障，整个测试周期较长。

对该测试的分析，认为WINCE6升级了文件系统和数据库版本，所以表现比WINCE5好。

数据库读写测试2

程序分别为C代码的SQLCE数据库程序和SQLite数据库程序，多线程满负荷对同数据库进行读写操作。SQLCE数据库程序表现正常，SQLite数据库程序只有在单线程时表现正常。查看SQLite源码发现，WINCE中使用的SQLite库精简掉了线程安全模式，所以不能保证多线程对数据库同时操作的稳定性。同时发现SQLite数据库每次添加数据，都会新建一个临时文件然后删除，每次添加数据都会重新打开数据库然后关闭，导致SQLite的CPU负载远远高于SQLCE。

对该测试的分析，目前版本的SQLite数据库并适合在WINCE平台上使用

1．数据满负荷读写时增加随机断电

运行之前文件读写程序，并增加外部定时断电，用于模拟实际现场环境可能出现的掉电情况。测试发现运行一段时间后发现WINCE6板子出现了文件系统故障，WEC7板子没有出现。

该测试英创分析认为CPU满负荷读写状态下突然掉电，可能是导致WINCE文件系统故障的主要原因。WEC7可能对文件系统做了近一步优化，所以表现比WINCE6好。因为设备意外断电总是不可避免，所以英创增加了备份还原工具来解决该问题。

2．多线程文件读写

根据客户反馈，编写测试程序模拟客户应用程序对文件系统进行读写操作，使用多个线程分别操作不同的文件进行读写。当实验读写数据量已经远远超过客户估算数据量，依然不能复现出客户反馈的文件系统故障。

该测试英创分析认为测试程序始终和客户应用程序存在巨大差异，这种差异导致实验难以复现客户反馈故障。

3．单文件多线程共享读写测试

同样根据客户反馈，编写测试程序模拟客户应用程序对文件系统进行读写操作，这一次，使用多个线程同时对同个文件进行读写操作。当实验读写数据量已经远远超过客户估算数据量时，同样无法复现出客户反馈的文件系统故障。

近期的实验发现

在近2个月里，我们采用了新的测试方法来检验FATFS。测试程序通过Timer，分别以60ms，90ms，150ms间隔读写3个不同文件。与以往测试的最大不同在于，之前测试是在文件中不停的添加新数据，此次测试是以覆盖的形式反复读写文件同一位置，即文件开头2048字节数据。

该实验读写量远远低于之前的测试，略60KB/s，CPU负载平时在20%以下，但是稳定在短时间内测试出文件系统故障（通常在一天内就能观察到文件系统故障）。此次试验的意义在于大大降低了测试规模，（此前由于文件系统故障出现几率太低，测试规模小了很可能测试不出结果。）

根据不同的实验条件，整个实验项目由十几个具体实验组成，实验数据见文章末尾附表。以下简要描述各个实验的情况。

1 - 3号实验

实验测试了英创EM928X平台下所有产品，发现不同硬件的产品在一定条件下均存在文件系统故障的概率，说明文件系统故障与硬件关系不大。

实验测试RAM注册表，和HIVE注册表的主板，实验结果说明文件系统故障与主板内核中注册表类型关系不大。

4 - 5号实验

实验中升级了测试程序，可以设置程序运行时间。实验采用对比的形式，一组实验板运行时间为90s，另一组实验板不限制测试时间，而外部断电时间为150s。这样，保证第一组测试版在外部断电时，没有进行文件操作。

实验结果，两组测试均出现了文件系统故障，实验结果看来，文件系统故障并非单纯因为进行文件读写操作时意外断电导致。

实验还修改了ECC校验，从校验1位改为校验8位。实验结果看来，文件系统故障与ECC校验关系也不大。

6 - 8号实验

实验测试了电源对文件系统的影响，实验结果看来，文件系统故障与电源关系不大。

实验测试对比了大容量FLASH和小容量FLASH，实验结果看来，文件系统故障与FLASH容量大小没有直接的关系，但容量越大故障出现的概率越小。

9号实验

采用了2组不同测试程序进行对比实验，一套测试程序为原测试程序，一套测试程序增加一组判断，当CPU负载率超过70%时暂时停止文件读写，当CPU负载率重新降到70%以下，再进行文件操作。

实验发现采用了监控CPU负载策略的板子再没有出现文件系统故障。

10 - 13号实验

为了排除程序差异性，重新编写测试程序，使测试使用相同测试程序，仅通过不同配置文件设置不同的文件读写策略。

实验再次验证，采用了监控CPU负载策略的板子没有发现文件系统故障，至少证明通过该策略，能大大降低文件系统故障概率。

进一步观察发现，板子每运行1分钟左右，大概文件重复写1000次左右时，CPU负载率会迅速升高到100%，这里应该是文件系统在后台做写平衡注操作。如果此时停止文件读写，CPU负载会很快下降至正常水平。反之，系统很大概率会一直维持CPU负载率100%状态。分析认为在系统进行写平衡操作时保持高频率文件读写，容易导致应用程序文件操作与后台的写平衡操作构成某种互锁而无法完成。

注：嵌入式板卡所使用的nandflash在写之前需要擦除，而nandflash只有大约10万次的擦写寿命。为了增加nandflash的使用寿命，文件系统会采用算法让程序均与写到nandflash各个位置，所以当文件系统发现nandflash某个位置读写过于频繁，就会将该处数据转移到其它位置上。

14 - 17号实验

Timer实际上是并在主线程里的单线程操作，客户在实际使用时更多使用多线程进行读写操作。14号至17号实验使用修改后的测试程序，程序使用多线程进行文件读写操作，读写间隔为50ms、100ms、150ms，与之前相似。实验发现，使用多线程，CPU负载比Timer低，文件系统出现故障几率比之前低，但是不采用CPU负载监控策略的板子依然会出现文件系统故障。

实验设定了不同CPU监控阈值，测试发现阈值设置到99，即仅在CPU负载达到99%以上时暂停文件读写，就可以有效避免出现文件系统故障。即只要CPU负载不达到100%，后台写平衡操作就能很快完成。

实验结论

从实验结果来看，文件系统故障最大诱因是系统内部做写平衡处理同时应用程序也在进行高频率文件读写。写平衡操作长时间无法完成容易导致文件系统故障。采用文章中提到的读写策略：即监控CPU负载率，在CPU负载超过一定阈值（推荐70%），暂停文件操作，等待CPU负载率降低到阈值以下（系统后台写平衡操作结束），可有效规避FATFS内部均衡操作与文件读写的冲突，从而保证文件系统的稳定运行。

客户程序如果高频率对文件进行覆盖读写操作，或是反复修改数据库某项值，会导致系统频繁进行写平衡操作。优化程序，降低系统写平衡操作的频率，也有助于提供文件系统稳定性。

小结

对基于WinCE的嵌入式系统，应用程序如果遵循以下2条规则：（1）采用多线程进行不同文件的读写操作；（2）基于CPU负载率的文件读写控制策略。就能够保证文件系统的稳定可靠运行。

附表实验记录

实验编号	日期	板卡名称	内核	Flash	板卡数	实验程序	外部断电	实验时长	实验结果
1	2018/12/13	EM9281	FSREGRAM	1G08	5套	test_filesys.exe V1.01	开80s,断5s	396小时/16771次	2套应用程序出错
2	2018/12/29	EM9281	FSREGHIVE	1G08	4套	test_filesys.exe V1.01	开80s,断5s	8小时/338次	3套应系统报错
EM9281	FSREGRAM	1G08	4套	test_filesys.exe V1.01	开80s,断5s	265小时/11223次	1套应用程序出错, 1套应系统报错
EM9287	FSREGRAM	1G08	3套	test_filesys.exe V1.01	开80s,断5s	8小时/338次	1套应用程序出错
EM9287	FSREGHIVE	1G08	4套	test_filesys.exe V1.01	开80s,断5s	95小时/4032次	1套应用程序出错，1套<-NandMonitor_Setup
EM9287	FSREGHIVE	1G08	6套	test_filesys.exe V1.01	开80s,断5s	88小时/3727次	1套应系统报错, <-NandMonitor_Setup
3	2019/01/02	EM9287	FSREGHIVE	1G08	10套	test_filesys.exe V1.01	开80s,断5s	151小时/6395次	2套应用程序出错
4	2019/01/09	EM9281	FSREGRAM	1G08	8套	test_filesys.exe V1.00(Parameters=”90”)	开150s,断5s	18小时/426次	1套应用程序出错
5	2019/01/10	EM9281	FSREGRAM(ecc校验8个及以上	1G08	8套	test_filesys.exe V1.00 Parameters=”S 90”	开150s,断5s	99小时/2299次	1套应用程序出错,1套死机
6	2019/01/15	EM9281	FSREGRAM（VDD电源）	1G08	8套	test_filesys.exe V1.03	开80s,断5s	14.9小时/632次	未出现异常
7	2019/01/16	ES9281	FSREGRAM（VDD电源）	2G08	8套	test_filesys.exe V1.03	开80s,断5s	23小时/976次	2套应用程序出错
EM9281	FSREGHIVE(纹波过冲)	1G08	8套	test_filesys.exe V1.03	开80s,断5s	16小时/677次	2019/01/25查看时有1套核报NK.EXE错误，且应用程序无法执行
8	2019/01/17	ES9281	FSREGHIVE(纹波过冲)	2G08	8套	test_filesys.exe	开80s,断5s 开300s,断5s 开540s,断5s	103.3小时/4376次 48小时/283次	1套应用程序出错
EM9281	FSREGHIVE(纹波过冲)	2G08	8套	test_filesys.exe V1.03	开80s,断5s	31.3小时/1327次	2019/01/25查看时有2套核报NK.EXE错误，且应用程序可以运行
9	2019/01/18	EM9281	FSREGHIVE(把盘分成2个)	2G08	8套	test_filesys.exe	开80s,断5s 开300s,断5s 开90s,断5s	72小时/3049次 48小时/283次	未出现异常
EM9281	FSREGHIVE	1G08	6套	test_filesys.exe(V1.03，超过70%就不写)	开80s,断5s	72/小时/3049次	未出现异常
EM9281	FSREGHIVE	1G08	6套	test_filesys.exe（V1.04 50 70%)	开300s,断5s	48小时/283次	未出现异常
EM9281	FSREGHIVE	1G08	6套	test_filesys.exe (V1.04，设置350 100%)	开90s,断5s	24小时/1016次	1套报NK.EXE错误，且应用程序可以运行
EM9281	FSREGHIVE	1G08	6套	test_filesys.exe（v1.01）	开540s,断5s	15小时/99次	1套报NK.EXE错误，且应用程序无法运行
10	2019/01/25	EM9281	FSREGHIVE	1G08	10套	FST.exe （v2.00）	开120s,断5s	21小时/607次	1套应用程序打不开
11	2019/01/26	EM9281	FSREGHIVE	1G08	10套	test_filesys.exe(V1.04 350 100%)	开120s,断5s	46.1小时/1328次	1套报NK.EXE错误，且应用程序无法运行，1套应用程序严重错误，无法打开
12	2019/01/28	EM9281	FSREGHIVE	1G08	10套	test_filesys.exe(V2.01 350 100%)	开120s,断5s	23.6小时/680次	1套应用程序打不开, 1套应用程序严重错误，无法打开
13	2019/01/29	EM9281	FSREGHIVE	1G08	10套	test_filesys.exe(V2.01b 350 100%)	开120s,断5s	4.09小时/118次	未出现异常
14	2019/01/31	EM9281	FSREGHIVE	1G08	10套	FST.exe（v2.02，70，50，100，150）	开120s,断5s	23.6小时/681次	未出现异常
EM9281	FSREGHIVE	1G08	10套	FST.exe（v2.02，80，50，100，150）	开120s,断5s	23.6小时/681次	未出现异常
EM9281	FSREGHIVE	1G08	10套	FST.exe（v2.02，100，50，100，150）	开120s,断5s	23.6小时/681次	未出现异常
15	2019/02/01	EM9281	FSREGHIVE	1G08	10套	FST.exe（v2.04，70，20，20，20）	开120s,断5s	23.6小时/681次	未出现异常
EM9281	FSREGHIVE	1G08	10套	FST.exe（v2.04，80，20，20，20）	开120s,断5s	23.6小时/681次	未出现异常
EM9281	FSREGHIVE	1G08	10套	FST.exe（v2.04，100，20，20，20）	开120s,断5s	23.6小时/681次	未出现异常
16	2019/02/02	EM9281	FSREGHIVE	1G08	10套	FST.exe（v2.04，-1）CPU负载最高100	开120s,断5s	23.6小时/681次	未出现异常
EM9281	FSREGHIVE	1G08	10套	FST.exe（v2.04，-1）CPU负载最高90	开120s,断5s	23.6小时/681次	未出现异常
EM9281	FSREGHIVE	1G08	5套	FST.exe（v2.04，-1）CPU负载最高80	开120s,断5s	23.6小时/681次	未出现异常
EM9281	FSREGHIVE	1G08	5套	FST.exe（v2.04，-1）CPU负载最高70	开120s,断5s	23.6小时/681次	未出现异常
17	2019/02/11	EM9281	FSREGHIVE	1G08	10套	FST.exe（v2.04，-1）CPU负载最高100	开180s,断5s	23.6小时/681次	2套出现文件系统故障
EM9281	FSREGHIVE	1G08	10套	FST.exe（v2.04，-1）CPU负载最高90	开180s,断5s	23.6小时/681次	未出现异常
EM9281	FSREGHIVE	1G08	5套	FST.exe（v2.04，-1）CPU负载最高80	开180s,断5s	23.6小时/681次	未出现异常
EM9281	FSREGHIVE	1G08	5套	FST.exe（v2.04，-1）CPU负载最高70	开180s,断5s	23.6小时/681次	未出现异常