99精品伊人亚洲|最近国产中文炮友|九草在线视频支援|AV网站大全最新|美女黄片免费观看|国产精品资源视频|精彩无码视频一区|91大神在线后入|伊人终合在线播放|久草综合久久中文

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

英創(chuàng)信息技術(shù)WinCE文件系統(tǒng)測試及故障分析簡介

英創(chuàng)信息技術(shù) ? 來源:英創(chuàng)信息技術(shù) ? 作者:英創(chuàng)信息技術(shù) ? 2020-02-07 11:15 ? 次閱讀
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

WINCE文件系統(tǒng)的偶發(fā)故障一直是WINCE系統(tǒng)最為棘手的問題,盡管出現(xiàn)故障的幾率不高,但對設(shè)備的穩(wěn)定運行造成嚴重影響。為了保證基于WinCE的嵌入式系統(tǒng)能穩(wěn)定可靠運行,英創(chuàng)公司對WINCE文件系統(tǒng)進行了長期分析測試,希望能找到有效辦法來規(guī)避WINCE文件系統(tǒng)故障。本文主要介紹英創(chuàng)在這方面的工作及獲得的成果。

先前的工作

過去多年,英創(chuàng)公司陸續(xù)做過很多工作改善WINCE文件系統(tǒng),也取得了一些成效。

1.將文件系統(tǒng)升級成exfat。

2.封裝文件讀寫庫,增加緩存空間,使文件讀寫盡量以整塊形式操作。

3.升級數(shù)據(jù)庫版本。

4.實現(xiàn)WINCE5->WINCE6->WEC7的升級。

5.修改NandFlash的ECC校驗。

6.將內(nèi)核注冊表類型由HIVE-Based注冊表替換為RAM-Based注冊表并測試其穩(wěn)定性。

7.增加文件備份恢復工具BFS。

先前的實驗工作

因為文件系統(tǒng)故障極低,使得通過實驗程序復現(xiàn)其故障變得很困難。在實驗室里通常大量板卡滿負荷連續(xù)工作1周以上可能才會發(fā)現(xiàn)有板卡出現(xiàn)文件系統(tǒng)故障。因為在實驗室運行程序始終與用戶現(xiàn)場使用存在差異,通過同樣CPU負載率完成近似文件讀寫量,確很難復現(xiàn)文件系統(tǒng)故障。英創(chuàng)公司也采用了很多不同的測試方法進行測試,例如:

數(shù)據(jù)輪詢讀寫測試

基礎(chǔ)的文件讀寫測試程序,程序滿負荷向nandflash寫記錄文件,寫滿后刪除最早記錄繼續(xù)添加新記錄。英創(chuàng)所有板卡均能通過該測試,該實驗程序也很難測試出文件系統(tǒng)故障。

數(shù)據(jù)庫讀寫測試1

程序為C#數(shù)據(jù)庫程序,程序滿負荷向SQLCE數(shù)據(jù)庫中不停添加記錄,該實驗測試了WINCE5,WINCE6的板子,其中WINCE5的板子有測試出文件系統(tǒng)故障,整個測試周期較長。

對該測試的分析,認為WINCE6升級了文件系統(tǒng)和數(shù)據(jù)庫版本,所以表現(xiàn)比WINCE5好。

數(shù)據(jù)庫讀寫測試2

程序分別為C代碼的SQLCE數(shù)據(jù)庫程序和SQLite數(shù)據(jù)庫程序,多線程滿負荷對同數(shù)據(jù)庫進行讀寫操作。SQLCE數(shù)據(jù)庫程序表現(xiàn)正常,SQLite數(shù)據(jù)庫程序只有在單線程時表現(xiàn)正常。查看SQLite源碼發(fā)現(xiàn),WINCE中使用的SQLite庫精簡掉了線程安全模式,所以不能保證多線程對數(shù)據(jù)庫同時操作的穩(wěn)定性。同時發(fā)現(xiàn)SQLite數(shù)據(jù)庫每次添加數(shù)據(jù),都會新建一個臨時文件然后刪除,每次添加數(shù)據(jù)都會重新打開數(shù)據(jù)庫然后關(guān)閉,導致SQLite的CPU負載遠遠高于SQLCE。

對該測試的分析,目前版本的SQLite數(shù)據(jù)庫并適合在WINCE平臺上使用

1.數(shù)據(jù)滿負荷讀寫時增加隨機斷電

運行之前文件讀寫程序,并增加外部定時斷電,用于模擬實際現(xiàn)場環(huán)境可能出現(xiàn)的掉電情況。測試發(fā)現(xiàn)運行一段時間后發(fā)現(xiàn)WINCE6板子出現(xiàn)了文件系統(tǒng)故障,WEC7板子沒有出現(xiàn)。

該測試英創(chuàng)分析認為CPU滿負荷讀寫狀態(tài)下突然掉電,可能是導致WINCE文件系統(tǒng)故障的主要原因。WEC7可能對文件系統(tǒng)做了近一步優(yōu)化,所以表現(xiàn)比WINCE6好。因為設(shè)備意外斷電總是不可避免,所以英創(chuàng)增加了備份還原工具來解決該問題。

2.多線程文件讀寫

根據(jù)客戶反饋,編寫測試程序模擬客戶應(yīng)用程序?qū)ξ募到y(tǒng)進行讀寫操作,使用多個線程分別操作不同的文件進行讀寫。當實驗讀寫數(shù)據(jù)量已經(jīng)遠遠超過客戶估算數(shù)據(jù)量,依然不能復現(xiàn)出客戶反饋的文件系統(tǒng)故障。

該測試英創(chuàng)分析認為測試程序始終和客戶應(yīng)用程序存在巨大差異,這種差異導致實驗難以復現(xiàn)客戶反饋故障。

3.單文件多線程共享讀寫測試

同樣根據(jù)客戶反饋,編寫測試程序模擬客戶應(yīng)用程序?qū)ξ募到y(tǒng)進行讀寫操作,這一次,使用多個線程同時對同個文件進行讀寫操作。當實驗讀寫數(shù)據(jù)量已經(jīng)遠遠超過客戶估算數(shù)據(jù)量時,同樣無法復現(xiàn)出客戶反饋的文件系統(tǒng)故障。

近期的實驗發(fā)現(xiàn)

在近2個月里,我們采用了新的測試方法來檢驗FATFS。測試程序通過Timer,分別以60ms,90ms,150ms間隔讀寫3個不同文件。與以往測試的最大不同在于,之前測試是在文件中不停的添加新數(shù)據(jù),此次測試是以覆蓋的形式反復讀寫文件同一位置,即文件開頭2048字節(jié)數(shù)據(jù)。

該實驗讀寫量遠遠低于之前的測試,略60KB/s,CPU負載平時在20%以下,但是穩(wěn)定在短時間內(nèi)測試出文件系統(tǒng)故障(通常在一天內(nèi)就能觀察到文件系統(tǒng)故障)。此次試驗的意義在于大大降低了測試規(guī)模,(此前由于文件系統(tǒng)故障出現(xiàn)幾率太低,測試規(guī)模小了很可能測試不出結(jié)果。)

根據(jù)不同的實驗條件,整個實驗項目由十幾個具體實驗組成,實驗數(shù)據(jù)見文章末尾附表。以下簡要描述各個實驗的情況。

1 - 3號實驗

實驗測試了英創(chuàng)EM928X平臺下所有產(chǎn)品,發(fā)現(xiàn)不同硬件的產(chǎn)品在一定條件下均存在文件系統(tǒng)故障的概率,說明文件系統(tǒng)故障與硬件關(guān)系不大。

實驗測試RAM注冊表,和HIVE注冊表的主板,實驗結(jié)果說明文件系統(tǒng)故障與主板內(nèi)核中注冊表類型關(guān)系不大。

4 - 5號實驗

實驗中升級了測試程序,可以設(shè)置程序運行時間。實驗采用對比的形式,一組實驗板運行時間為90s,另一組實驗板不限制測試時間,而外部斷電時間為150s。這樣,保證第一組測試版在外部斷電時,沒有進行文件操作。

實驗結(jié)果,兩組測試均出現(xiàn)了文件系統(tǒng)故障,實驗結(jié)果看來,文件系統(tǒng)故障并非單純因為進行文件讀寫操作時意外斷電導致。

實驗還修改了ECC校驗,從校驗1位改為校驗8位。實驗結(jié)果看來,文件系統(tǒng)故障與ECC校驗關(guān)系也不大。

6 - 8號實驗

實驗測試了電源對文件系統(tǒng)的影響,實驗結(jié)果看來,文件系統(tǒng)故障與電源關(guān)系不大。

實驗測試對比了大容量FLASH和小容量FLASH,實驗結(jié)果看來,文件系統(tǒng)故障與FLASH容量大小沒有直接的關(guān)系,但容量越大故障出現(xiàn)的概率越小。

9號實驗

采用了2組不同測試程序進行對比實驗,一套測試程序為原測試程序,一套測試程序增加一組判斷,當CPU負載率超過70%時暫時停止文件讀寫,當CPU負載率重新降到70%以下,再進行文件操作。

實驗發(fā)現(xiàn)采用了監(jiān)控CPU負載策略的板子再沒有出現(xiàn)文件系統(tǒng)故障。

10 - 13號實驗

為了排除程序差異性,重新編寫測試程序,使測試使用相同測試程序,僅通過不同配置文件設(shè)置不同的文件讀寫策略。

實驗再次驗證,采用了監(jiān)控CPU負載策略的板子沒有發(fā)現(xiàn)文件系統(tǒng)故障,至少證明通過該策略,能大大降低文件系統(tǒng)故障概率。

進一步觀察發(fā)現(xiàn),板子每運行1分鐘左右,大概文件重復寫1000次左右時,CPU負載率會迅速升高到100%,這里應(yīng)該是文件系統(tǒng)在后臺做寫平衡注操作。如果此時停止文件讀寫,CPU負載會很快下降至正常水平。反之,系統(tǒng)很大概率會一直維持CPU負載率100%狀態(tài)。分析認為在系統(tǒng)進行寫平衡操作時保持高頻率文件讀寫,容易導致應(yīng)用程序文件操作與后臺的寫平衡操作構(gòu)成某種互鎖而無法完成。

注:嵌入式板卡所使用的nandflash在寫之前需要擦除,而nandflash只有大約10萬次的擦寫壽命。為了增加nandflash的使用壽命,文件系統(tǒng)會采用算法讓程序均與寫到nandflash各個位置,所以當文件系統(tǒng)發(fā)現(xiàn)nandflash某個位置讀寫過于頻繁,就會將該處數(shù)據(jù)轉(zhuǎn)移到其它位置上。

14 - 17號實驗

Timer實際上是并在主線程里的單線程操作,客戶在實際使用時更多使用多線程進行讀寫操作。14號至17號實驗使用修改后的測試程序,程序使用多線程進行文件讀寫操作,讀寫間隔為50ms、100ms、150ms,與之前相似。實驗發(fā)現(xiàn),使用多線程,CPU負載比Timer低,文件系統(tǒng)出現(xiàn)故障幾率比之前低,但是不采用CPU負載監(jiān)控策略的板子依然會出現(xiàn)文件系統(tǒng)故障。

實驗設(shè)定了不同CPU監(jiān)控閾值,測試發(fā)現(xiàn)閾值設(shè)置到99,即僅在CPU負載達到99%以上時暫停文件讀寫,就可以有效避免出現(xiàn)文件系統(tǒng)故障。即只要CPU負載不達到100%,后臺寫平衡操作就能很快完成。

實驗結(jié)論

從實驗結(jié)果來看,文件系統(tǒng)故障最大誘因是系統(tǒng)內(nèi)部做寫平衡處理同時應(yīng)用程序也在進行高頻率文件讀寫。寫平衡操作長時間無法完成容易導致文件系統(tǒng)故障。采用文章中提到的讀寫策略:即監(jiān)控CPU負載率,在CPU負載超過一定閾值(推薦70%),暫停文件操作,等待CPU負載率降低到閾值以下(系統(tǒng)后臺寫平衡操作結(jié)束),可有效規(guī)避FATFS內(nèi)部均衡操作與文件讀寫的沖突,從而保證文件系統(tǒng)的穩(wěn)定運行。

客戶程序如果高頻率對文件進行覆蓋讀寫操作,或是反復修改數(shù)據(jù)庫某項值,會導致系統(tǒng)頻繁進行寫平衡操作。優(yōu)化程序,降低系統(tǒng)寫平衡操作的頻率,也有助于提供文件系統(tǒng)穩(wěn)定性。

小結(jié)

對基于WinCE的嵌入式系統(tǒng),應(yīng)用程序如果遵循以下2條規(guī)則:(1)采用多線程進行不同文件的讀寫操作;(2)基于CPU負載率的文件讀寫控制策略。就能夠保證文件系統(tǒng)的穩(wěn)定可靠運行。

附表實驗記錄

實驗編號 日期 板卡名稱 內(nèi)核 Flash 板卡數(shù) 實驗程序 外部斷電 實驗時長 實驗結(jié)果
1 2018/12/13 EM9281 FSREGRAM 1G08 5套 test_filesys.exe V1.01 開80s,斷5s 396小時/16771次 2套應(yīng)用程序出錯
2 2018/12/29 EM9281 FSREGHIVE 1G08 4套 test_filesys.exe V1.01 開80s,斷5s 8小時/338次 3套應(yīng)系統(tǒng)報錯
EM9281 FSREGRAM 1G08 4套 test_filesys.exe V1.01 開80s,斷5s 265小時/11223次 1套應(yīng)用程序出錯, 1套應(yīng)系統(tǒng)報錯
EM9287 FSREGRAM 1G08 3套 test_filesys.exe V1.01 開80s,斷5s 8小時/338次 1套應(yīng)用程序出錯
EM9287 FSREGHIVE 1G08 4套 test_filesys.exe V1.01 開80s,斷5s 95小時/4032次 1套應(yīng)用程序出錯,1套<-NandMonitor_Setup
EM9287 FSREGHIVE 1G08 6套 test_filesys.exe V1.01 開80s,斷5s 88小時/3727次 1套應(yīng)系統(tǒng)報錯, <-NandMonitor_Setup
3 2019/01/02 EM9287 FSREGHIVE 1G08 10套 test_filesys.exe V1.01 開80s,斷5s 151小時/6395次 2套應(yīng)用程序出錯
4 2019/01/09 EM9281 FSREGRAM 1G08 8套 test_filesys.exe V1.00(Parameters=”90”) 開150s,斷5s 18小時/426次 1套應(yīng)用程序出錯
5 2019/01/10 EM9281 FSREGRAM(ecc校驗8個及以上 1G08 8套 test_filesys.exe V1.00 Parameters=”S 90” 開150s,斷5s 99小時/2299次 1套應(yīng)用程序出錯,1套死機
6 2019/01/15 EM9281 FSREGRAM(VDD電源) 1G08 8套 test_filesys.exe V1.03 開80s,斷5s 14.9小時/632次 未出現(xiàn)異常
7 2019/01/16 ES9281 FSREGRAM(VDD電源) 2G08 8套 test_filesys.exe V1.03 開80s,斷5s 23小時/976次 2套應(yīng)用程序出錯
EM9281 FSREGHIVE(紋波過沖) 1G08 8套 test_filesys.exe V1.03 開80s,斷5s 16小時/677次 2019/01/25查看時有1套核報NK.EXE錯誤,且應(yīng)用程序無法執(zhí)行
8 2019/01/17 ES9281 FSREGHIVE(紋波過沖) 2G08 8套 test_filesys.exe 開80s,斷5s
開300s,斷5s
開540s,斷5s
103.3小時/4376次
48小時/283次
1套應(yīng)用程序出錯
EM9281 FSREGHIVE(紋波過沖) 2G08 8套 test_filesys.exe V1.03 開80s,斷5s 31.3小時/1327次 2019/01/25查看時有2套核報NK.EXE錯誤,且應(yīng)用程序可以運行
9 2019/01/18 EM9281 FSREGHIVE(把盤分成2個) 2G08 8套 test_filesys.exe 開80s,斷5s
開300s,斷5s
開90s,斷5s
72小時/3049次
48小時/283次
未出現(xiàn)異常
EM9281 FSREGHIVE 1G08 6套 test_filesys.exe(V1.03,超過70%就不寫) 開80s,斷5s 72/小時/3049次 未出現(xiàn)異常
EM9281 FSREGHIVE 1G08 6套 test_filesys.exe(V1.04 50 70%) 開300s,斷5s 48小時/283次 未出現(xiàn)異常
EM9281 FSREGHIVE 1G08 6套 test_filesys.exe (V1.04,設(shè)置350 100%) 開90s,斷5s 24小時/1016次 1套報NK.EXE錯誤,且應(yīng)用程序可以運行
EM9281 FSREGHIVE 1G08 6套 test_filesys.exe(v1.01) 開540s,斷5s 15小時/99次 1套報NK.EXE錯誤,且應(yīng)用程序無法運行
10 2019/01/25 EM9281 FSREGHIVE 1G08 10套 FST.exe (v2.00) 開120s,斷5s 21小時/607次 1套應(yīng)用程序打不開
11 2019/01/26 EM9281 FSREGHIVE 1G08 10套 test_filesys.exe(V1.04 350 100%) 開120s,斷5s 46.1小時/1328次 1套報NK.EXE錯誤,且應(yīng)用程序無法運行,1套應(yīng)用程序嚴重錯誤,無法打開
12 2019/01/28 EM9281 FSREGHIVE 1G08 10套 test_filesys.exe(V2.01 350 100%) 開120s,斷5s 23.6小時/680次 1套應(yīng)用程序打不開, 1套應(yīng)用程序嚴重錯誤,無法打開
13 2019/01/29 EM9281 FSREGHIVE 1G08 10套 test_filesys.exe(V2.01b 350 100%) 開120s,斷5s 4.09小時/118次 未出現(xiàn)異常
14 2019/01/31 EM9281 FSREGHIVE 1G08 10套 FST.exe(v2.02,70,50,100,150) 開120s,斷5s 23.6小時/681次 未出現(xiàn)異常
EM9281 FSREGHIVE 1G08 10套 FST.exe(v2.02,80,50,100,150) 開120s,斷5s 23.6小時/681次 未出現(xiàn)異常
EM9281 FSREGHIVE 1G08 10套 FST.exe(v2.02,100,50,100,150) 開120s,斷5s 23.6小時/681次 未出現(xiàn)異常
15 2019/02/01 EM9281 FSREGHIVE 1G08 10套 FST.exe(v2.04,70,20,20,20) 開120s,斷5s 23.6小時/681次 未出現(xiàn)異常
EM9281 FSREGHIVE 1G08 10套 FST.exe(v2.04,80,20,20,20) 開120s,斷5s 23.6小時/681次 未出現(xiàn)異常
EM9281 FSREGHIVE 1G08 10套 FST.exe(v2.04,100,20,20,20) 開120s,斷5s 23.6小時/681次 未出現(xiàn)異常
16 2019/02/02 EM9281 FSREGHIVE 1G08 10套 FST.exe(v2.04,-1)CPU負載最高100 開120s,斷5s 23.6小時/681次 未出現(xiàn)異常
EM9281 FSREGHIVE 1G08 10套 FST.exe(v2.04,-1)CPU負載最高90 開120s,斷5s 23.6小時/681次 未出現(xiàn)異常
EM9281 FSREGHIVE 1G08 5套 FST.exe(v2.04,-1)CPU負載最高80 開120s,斷5s 23.6小時/681次 未出現(xiàn)異常
EM9281 FSREGHIVE 1G08 5套 FST.exe(v2.04,-1)CPU負載最高70 開120s,斷5s 23.6小時/681次 未出現(xiàn)異常
17 2019/02/11 EM9281 FSREGHIVE 1G08 10套 FST.exe(v2.04,-1)CPU負載最高100 開180s,斷5s 23.6小時/681次 2套出現(xiàn)文件系統(tǒng)故障
EM9281 FSREGHIVE 1G08 10套 FST.exe(v2.04,-1)CPU負載最高90 開180s,斷5s 23.6小時/681次 未出現(xiàn)異常
EM9281 FSREGHIVE 1G08 5套 FST.exe(v2.04,-1)CPU負載最高80 開180s,斷5s 23.6小時/681次 未出現(xiàn)異常
EM9281 FSREGHIVE 1G08 5套 FST.exe(v2.04,-1)CPU負載最高70 開180s,斷5s 23.6小時/681次 未出現(xiàn)異常

其他

測試中使用的測試程序及源碼,客戶可以聯(lián)系英創(chuàng)工程師獲得。

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學習之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
收藏 人收藏
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

    評論

    相關(guān)推薦
    熱點推薦

    飛凌嵌入式ElfBoard ELF 1板卡-文件系統(tǒng)簡介

    作為物理磁盤來使用的一種技術(shù)。它并非一個實際的文件系統(tǒng),而是一種將實際的文件系統(tǒng)裝入內(nèi)存的機制,并且可以作為根文件系統(tǒng)。將一些經(jīng)常被訪問而又不會更改的
    發(fā)表于 06-19 17:22

    科普|信創(chuàng)是什么?一文讀懂“信息技術(shù)應(yīng)用創(chuàng)新”戰(zhàn)略

    什么是信創(chuàng)?信創(chuàng),即“信息技術(shù)應(yīng)用創(chuàng)新”,是國家推動IT系統(tǒng)自主可控、安全可控的重要戰(zhàn)略工程。它不僅是技術(shù)層面的創(chuàng)新,更承載著保障國家網(wǎng)絡(luò)安
    的頭像 發(fā)表于 06-13 10:06 ?1982次閱讀
    科普|信<b class='flag-5'>創(chuàng)</b>是什么?一文讀懂“<b class='flag-5'>信息技術(shù)</b>應(yīng)用創(chuàng)新”戰(zhàn)略

    服務(wù)器數(shù)據(jù)恢復—ocfs2文件系統(tǒng)被格式化為Ext4文件系統(tǒng)的數(shù)據(jù)恢復案例

    服務(wù)器存儲數(shù)據(jù)恢復環(huán)境&故障: 人為誤操作將Ext4文件系統(tǒng)誤裝入一臺服務(wù)器存儲上的Ocfs2文件系統(tǒng)數(shù)據(jù)卷上,導致原Ocfs2文件系統(tǒng)被格式化為Ext4
    的頭像 發(fā)表于 06-10 12:03 ?210次閱讀
    服務(wù)器數(shù)據(jù)恢復—ocfs2<b class='flag-5'>文件系統(tǒng)</b>被格式化為Ext4<b class='flag-5'>文件系統(tǒng)</b>的數(shù)據(jù)恢復案例

    電纜故障定位系統(tǒng)原理分析

    (適用于高阻/閃絡(luò)故障),這種方法具有更高精度,測量更為準確。 電纜故障定位技術(shù)融合了多種物理與信息技術(shù),如行波測距法、信號反射法等,結(jié)合分布式傳感與物聯(lián)網(wǎng)
    的頭像 發(fā)表于 04-03 11:19 ?325次閱讀
    電纜<b class='flag-5'>故障</b>定位<b class='flag-5'>系統(tǒng)</b>原理<b class='flag-5'>分析</b>

    如何正確選擇嵌入式文件系統(tǒng)?

    Linux嵌入式系統(tǒng)中,文件系統(tǒng)和緩存機制常導致數(shù)據(jù)存儲穩(wěn)定性問題。本文通過案例分析原因,對比不同文件系統(tǒng)特性,為開發(fā)者提供優(yōu)化建議,助力提升數(shù)據(jù)穩(wěn)定性和
    的頭像 發(fā)表于 03-17 11:35 ?500次閱讀
    如何正確選擇嵌入式<b class='flag-5'>文件系統(tǒng)</b>?

    NFS網(wǎng)絡(luò)文件系統(tǒng)深度解析

    NFS:Network File System 網(wǎng)絡(luò)文件系統(tǒng),基于內(nèi)核的文件系統(tǒng)。Sun 公司開發(fā),通過使用 NFS,用戶和程序可以像訪問本地文件一樣訪問遠端系統(tǒng)上的
    的頭像 發(fā)表于 03-01 14:15 ?703次閱讀

    SMT加工中的故障排除:寧波中電集創(chuàng)系統(tǒng)化實踐

    和診斷至關(guān)重要。公司通過建立完善的故障記錄系統(tǒng),確保技術(shù)人員能夠快速獲取關(guān)鍵信息。 接下來,通過視覺檢查初步查找明顯的物理異常,例如焊料橋接、短路、開路、元件錯位或缺失等。寧波中電集
    發(fā)表于 02-14 12:48

    防止根文件系統(tǒng)破壞,OverlayRootfs 讓你的設(shè)備更安全

    OverlayRootfs介紹OverlayRootfs是指利用OverlayFS技術(shù)創(chuàng)建的根文件系統(tǒng)(rootfilesystem)。OverlayFS是一種聯(lián)合文件系統(tǒng)(UnionFS),允許將
    的頭像 發(fā)表于 01-08 16:33 ?1434次閱讀
    防止根<b class='flag-5'>文件系統(tǒng)</b>破壞,OverlayRootfs 讓你的設(shè)備更安全

    stm32單片機基于rt-thread 的 littlefs 文件系統(tǒng) 的使用

    簡介littlefs是ARM官方推出的,專為嵌入式系統(tǒng)設(shè)計的文件系統(tǒng),相比傳統(tǒng)的文件系統(tǒng),littlefs具有以下優(yōu)點:1、自帶擦寫均衡2、支持掉電保護3、占用的
    的頭像 發(fā)表于 11-06 08:04 ?2998次閱讀
    stm32單片機基于rt-thread 的 littlefs <b class='flag-5'>文件系統(tǒng)</b> 的使用

    中科創(chuàng)達榮獲2024年軟件和信息技術(shù)服務(wù)優(yōu)秀企業(yè)

    及前百家企業(yè)”名單。中科創(chuàng)達憑借非凡的技術(shù)實力與持續(xù)的創(chuàng)新能力,成功入選“2024年度軟件和信息技術(shù)服務(wù)競爭力百強企業(yè)”以及“2024年軟件和信息技術(shù)服務(wù)優(yōu)秀企業(yè)”。
    的頭像 發(fā)表于 10-30 11:44 ?970次閱讀

    Linux根文件系統(tǒng)的掛載過程

    Linux根文件系統(tǒng)(rootfs)是Linux系統(tǒng)中所有其他文件系統(tǒng)和目錄的起點,它是內(nèi)核啟動時掛載的第一個文件系統(tǒng)
    的頭像 發(fā)表于 10-05 16:50 ?968次閱讀

    如何構(gòu)建Linux根文件系統(tǒng)

    構(gòu)建Linux根文件系統(tǒng)是一個涉及多個步驟和概念的過程,它對于Linux系統(tǒng)的啟動和運行至關(guān)重要。
    的頭像 發(fā)表于 10-05 16:47 ?684次閱讀

    想提高開發(fā)效率,不要忘記文件系統(tǒng)

    ?同學們都知道,開發(fā)過程中文件系統(tǒng)的重要性,同樣的,4G-Cat.1模組的文件系統(tǒng)也非常重要,它通常與數(shù)據(jù)傳輸速度、存儲效率,以及數(shù)據(jù)安全性等有非常重要的關(guān)系,在應(yīng)用開發(fā)中也非常重要。
    的頭像 發(fā)表于 09-21 08:18 ?541次閱讀
    想提高開發(fā)效率,不要忘記<b class='flag-5'>文件系統(tǒng)</b>

    服務(wù)器數(shù)據(jù)恢復—xfs文件系統(tǒng)服務(wù)器數(shù)據(jù)恢復案例

    某公司一臺服務(wù)器,連接了一臺存儲。該服務(wù)器安裝linux操作系統(tǒng),文件系統(tǒng)為xfs。 在運行過程中該服務(wù)器出現(xiàn)故障,管理員使用xfs_repair工具試圖對xfs文件系統(tǒng)進行修復但失
    的頭像 發(fā)表于 08-19 10:49 ?600次閱讀

    如何修改buildroot和debian文件系統(tǒng)

    本文檔主要介紹在沒有編譯環(huán)境的情況下,如何修改buildroot和debian文件系統(tǒng)方法,如在buildroot文件系統(tǒng)中添加文件、修改目錄等文件操作,在debian
    的頭像 發(fā)表于 07-22 17:46 ?888次閱讀
    如何修改buildroot和debian<b class='flag-5'>文件系統(tǒng)</b>