0
  • 聊天消息
  • 系统消息
  • 评论与回复
登录后你可以
  • 下载海量资料
  • 学习在线课程
  • 观看技术视频
  • 写文章/发帖/加入社区
会员中心
创作中心

完善资料让更多小伙伴认识你,还能领取20积分哦,立即完善>

3天内不再提示

英创信息技术WinCE文件系统测试及故障分析简介

英创信息技术 来源:英创信息技术 作者:英创信息技术 2020-02-07 11:15 次阅读
加入交流群
微信小助手二维码

扫码添加小助手

加入工程师交流群

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次 未出现异常

其他

测试中使用的测试程序及源码,客户可以联系英创工程师获得。

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

    关注

    41

    文章

    3716

    浏览量

    133106
收藏 人收藏
加入交流群
微信小助手二维码

扫码添加小助手

加入工程师交流群

    评论

    相关推荐
    热点推荐

    明晚8点|睿擎文件系统实战:从开发到发布全流程解析

    文件操作到镜像发布,一次直播掌握完整开发流程!在嵌入式系统开发中,文件系统是数据存储、配置管理和资源访问的核心基础。然而在实际开发中,文件操作效率低下、镜像打包流程复杂、
    的头像 发表于 11-11 11:53 376次阅读
    明晚8点|睿擎<b class='flag-5'>文件系统</b>实战:从开发到发布全流程解析

    睿擎派文件系统指南:从开发到发布全流程实践 | 技术解析

    在嵌入式系统开发中,文件系统扮演着至关重要的角色,它负责数据的持久化存储、配置文件管理和资源访问等核心功能。睿擎平台提供了一套完整的文件系统解决方案,从开发阶段的API调用到调试阶段的
    的头像 发表于 11-05 18:13 7698次阅读
    睿擎派<b class='flag-5'>文件系统</b>指南:从开发到发布全流程实践 | <b class='flag-5'>技术</b>解析

    技术贴|【RK3588】ELF 2开发板如何添加exFAT和NTFS文件系统格式

    基于RK3588设计的ELF2开发板在搭载Desktop22.04系统时,对TF卡的文件系统支持存在以下限制:不支持exFAT格式;支持NTFS格式,但需手动挂载;针对上述兼容性问题,本文将介绍
    的头像 发表于 08-27 17:21 3206次阅读
    <b class='flag-5'>技术</b>贴|【RK3588】ELF 2开发板如何添加exFAT和NTFS<b class='flag-5'>文件系统</b>格式

    Linux三大主流文件系统解析

    还在为选择哪个文件系统而纠结?作为一名摸爬滚打多年的运维老鸟,我将用最接地气的方式,带你彻底搞懂 Linux 三大主流文件系统的奥秘。
    的头像 发表于 08-05 17:37 1043次阅读

    佛瑞亚如何通过信息技术推动业务增长

    在数字化、信息化的浪潮下,信息技术已经不仅是后台工具,更成为驱动企业发展的关键力量。本期Women Inspiring Mobility,我们采访了佛瑞亚中国区信息技术总监马瑛,了解她和团队如何将
    的头像 发表于 07-29 14:00 729次阅读

    飞凌嵌入式ElfBoard ELF 1板卡-文件系统简介

    作为物理磁盘来使用的一种技术。它并非一个实际的文件系统,而是一种将实际的文件系统装入内存的机制,并且可以作为根文件系统。将一些经常被访问而又不会更改的
    发表于 06-19 17:22

    科普|信是什么?一文读懂“信息技术应用创新”战略

    什么是信?信,即“信息技术应用创新”,是国家推动IT系统自主可控、安全可控的重要战略工程。它不仅是技术层面的创新,更承载着保障国家网络安
    的头像 发表于 06-13 10:06 6311次阅读
    科普|信<b class='flag-5'>创</b>是什么?一文读懂“<b class='flag-5'>信息技术</b>应用创新”战略

    服务器数据恢复—ocfs2文件系统被格式化为Ext4文件系统的数据恢复案例

    服务器存储数据恢复环境&故障: 人为误操作将Ext4文件系统误装入一台服务器存储上的Ocfs2文件系统数据卷上,导致原Ocfs2文件系统被格式化为Ext4
    的头像 发表于 06-10 12:03 563次阅读
    服务器数据恢复—ocfs2<b class='flag-5'>文件系统</b>被格式化为Ext4<b class='flag-5'>文件系统</b>的数据恢复案例

    电缆故障定位系统原理分析

    (适用于高阻/闪络故障),这种方法具有更高精度,测量更为准确。 电缆故障定位技术融合了多种物理与信息技术,如行波测距法、信号反射法等,结合分布式传感与物联网
    的头像 发表于 04-03 11:19 670次阅读
    电缆<b class='flag-5'>故障</b>定位<b class='flag-5'>系统</b>原理<b class='flag-5'>分析</b>

    如何正确选择嵌入式文件系统

    Linux嵌入式系统中,文件系统和缓存机制常导致数据存储稳定性问题。本文通过案例分析原因,对比不同文件系统特性,为开发者提供优化建议,助力提升数据稳定性和
    的头像 发表于 03-17 11:35 863次阅读
    如何正确选择嵌入式<b class='flag-5'>文件系统</b>?

    NFS网络文件系统深度解析

    NFS:Network File System 网络文件系统,基于内核的文件系统。Sun 公司开发,通过使用 NFS,用户和程序可以像访问本地文件一样访问远端系统上的
    的头像 发表于 03-01 14:15 1169次阅读

    SMT加工中的故障排除:宁波中电集系统化实践

    和诊断至关重要。公司通过建立完善的故障记录系统,确保技术人员能够快速获取关键信息。 接下来,通过视觉检查初步查找明显的物理异常,例如焊料桥接、短路、开路、元件错位或缺失等。宁波中电集
    发表于 02-14 12:48

    服务器数据恢复—Zfs文件系统服务器数据恢复案例

    服务器数据恢复环境&故障: 一台zfs文件系统的服务器,管理员误操作删除了服务器上的数据。
    的头像 发表于 01-16 17:27 631次阅读

    防止根文件系统破坏,OverlayRootfs 让你的设备更安全

    OverlayRootfs介绍OverlayRootfs是指利用OverlayFS技术创建的根文件系统(rootfilesystem)。OverlayFS是一种联合文件系统(UnionFS),允许将
    的头像 发表于 01-08 16:33 2456次阅读
    防止根<b class='flag-5'>文件系统</b>破坏,OverlayRootfs 让你的设备更安全

    关于更新openharmony文件系统时遇到的问题

    用的固件,文件系统,内核是之前的,之前版本用起来没问题。但是 用下面三个的时候 固件可以正常烧录,也按照文档里面加载了环境变量,但是烧录内核和文件系统(都是U盘更新的)的时候出现了这样的问题
    发表于 12-30 11:55