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

    文章

    3587

    浏览量

    129435
收藏 人收藏

    评论

    相关推荐

    华纳云:VFS在提升文件系统性能方面的具体实践

    VFS(Virtual File System)通过提供统一的接口和抽象层,使得操作系统能够以高效的方式管理和访问不同的文件系统。以下是一些VFS在提升文件系统性能方面的具体实践示例: 统一的
    的头像 发表于 11-27 15:59 158次阅读

    stm32单片机基于rt-thread 的 littlefs 文件系统 的使用

    简介littlefs是ARM官方推出的,专为嵌入式系统设计的文件系统,相比传统的文件系统,littlefs具有以下优点:1、自带擦写均衡2、支持掉电保护3、占用的
    的头像 发表于 11-06 08:04 616次阅读
    stm32单片机基于rt-thread 的 littlefs <b class='flag-5'>文件系统</b> 的使用

    中科达荣获2024年软件和信息技术服务优秀企业

    及前百家企业”名单。中科达凭借非凡的技术实力与持续的创新能力,成功入选“2024年度软件和信息技术服务竞争力百强企业”以及“2024年软件和信息技术服务优秀企业”。
    的头像 发表于 10-30 11:44 461次阅读

    服务器数据恢复—EXT3文件系统下误删除数据的恢复案例

    服务器数据恢复环境: 邮件服务器中有一组由8块盘组成的RAID5阵列, 上层是Linux操作系统+EXT3文件系统。 服务器故障: 由于误删除导致文件系统中的邮件数据丢失。
    的头像 发表于 10-23 15:11 158次阅读
    服务器数据恢复—EXT3<b class='flag-5'>文件系统</b>下误删除数据的恢复案例

    Linux根文件系统的挂载过程

    Linux根文件系统(rootfs)是Linux系统中所有其他文件系统和目录的起点,它是内核启动时挂载的第一个文件系统
    的头像 发表于 10-05 16:50 403次阅读

    如何构建Linux根文件系统

    构建Linux根文件系统是一个涉及多个步骤和概念的过程,它对于Linux系统的启动和运行至关重要。
    的头像 发表于 10-05 16:47 292次阅读

    想提高开发效率,不要忘记文件系统

    ​同学们都知道,开发过程中文件系统的重要性,同样的,4G-Cat.1模组的文件系统也非常重要,它通常与数据传输速度、存储效率,以及数据安全性等有非常重要的关系,在应用开发中也非常重要。
    的头像 发表于 09-21 08:18 232次阅读
    想提高开发效率,不要忘记<b class='flag-5'>文件系统</b>

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

    某公司一台服务器,连接了一台存储。该服务器安装linux操作系统文件系统为xfs。 在运行过程中该服务器出现故障,管理员使用xfs_repair工具试图对xfs文件系统进行修复但失
    的头像 发表于 08-19 10:49 287次阅读

    如何更改Linux文件系统终端显示颜色

    自己制作的简单 Linux 文件系统,你会发现终端显示为黑白色,很不好看
    的头像 发表于 08-12 17:29 527次阅读
    如何更改Linux<b class='flag-5'>文件系统</b>终端显示颜色

    如何修改buildroot和debian文件系统

    本文档主要介绍在没有编译环境的情况下,如何修改buildroot和debian文件系统方法,如在buildroot文件系统中添加文件、修改目录等文件操作,在debian
    的头像 发表于 07-22 17:46 458次阅读
    如何修改buildroot和debian<b class='flag-5'>文件系统</b>

    linux--sysfs文件系统

    sysfs文件系统 sysfs,全称为System Filesystem,是一个由Linux内核实现的虚拟文件系统。它扮演着一个桥梁的角色,将内核中的设备和驱动程序信息文件的形式呈现
    的头像 发表于 07-08 11:37 841次阅读
    linux--sysfs<b class='flag-5'>文件系统</b>

    【嵌入式SD NAND】基于FATFS/Littlefs文件系统的日志框架实现

    `deinit`3.5全部代码汇总4.测试5.总结1.概述那么在移植好了文件系统之后,我们又应该如何应用文件系统呢?很多人会说,这个简单,就操作文件嘛!open、rea
    的头像 发表于 03-14 18:12 1156次阅读
    【嵌入式SD NAND】基于FATFS/Littlefs<b class='flag-5'>文件系统</b>的日志框架实现

    Linux系统如何扩展文件系统

    当数据盘没有创建分区,只在设备上创建了文件系统。或者格式化了硬盘,就直接mount上系统使用。
    的头像 发表于 02-21 09:53 834次阅读

    鸿蒙轻内核源码分析:虚拟文件系统 VFS

    VFS(Virtual File System)是文件系统的虚拟层,它不是一个实际的文件系统,而是一个异构文件系统之上的软件粘合层,为用户提供统一的类 Unix 文件操作接口。由于不同
    的头像 发表于 02-18 14:50 805次阅读

    【服务器数据恢复】UFS2文件系统数据恢复案例

    不稳,服务器非正常关机,重启服务器后发现ESXI虚拟化系统无法连接存储。工作人员对服务器进行故障排查,发现UFS2文件系统出现故障,于是fsck修复UFS2
    的头像 发表于 01-09 14:53 884次阅读