1.文件系統(tǒng)斷電可靠性問題
?
“一切皆是文件”,這是Linux生態(tài)系統(tǒng)中最常被引用的經(jīng)驗(yàn)法則之一。這體現(xiàn)了文件以及文件系統(tǒng)可靠性對(duì)Linux操作系統(tǒng)的重要性。
提高可靠性最簡(jiǎn)單的方法就是把文件系統(tǒng)設(shè)置為只讀狀態(tài)。即禁止對(duì)其中的內(nèi)容作任何修改。這樣,文件系統(tǒng)便不會(huì)因?qū)懭氩僮髌陂g發(fā)生故障而受損。當(dāng)然,您也可以不這么做。配置數(shù)據(jù)、日志文件、臨時(shí)信息及其他數(shù)據(jù)需要一個(gè)可靠的可寫文件系統(tǒng)。
圖1:Linux內(nèi)核中的文件系統(tǒng)
考慮到汽車應(yīng)用的獨(dú)特需求,斷電時(shí)確保系統(tǒng)的可靠性非常重要。汽車嵌入式系統(tǒng)面臨兩種高風(fēng)險(xiǎn):意外失電以及意外失電時(shí)處理不當(dāng)導(dǎo)致功能失效。顯然,我們都不希望自己的汽車因電池電量不足而被拖到維修門店。
1.1. ?背景 — 到底什么是“文件系統(tǒng)”?
?
對(duì)于Linux設(shè)置,無(wú)論是嵌入式還是桌面設(shè)置,文件系統(tǒng)層都是持久性和易失性存儲(chǔ)器的核心。如圖1所示,當(dāng)某項(xiàng)應(yīng)用想與系統(tǒng)中的數(shù)據(jù)交互時(shí),可通過(guò)虛擬文件系統(tǒng)或VFS實(shí)現(xiàn)。
VFS層可抽象出底層文件系統(tǒng)實(shí)現(xiàn)的差異。事實(shí)上,我們?cè)谂c文件交互時(shí)經(jīng)常會(huì)看到向上呈現(xiàn)的現(xiàn)象,例如“/home/user/myfile.txt”。
實(shí)際文件系統(tǒng)實(shí)現(xiàn)發(fā)生在VFS下。它的主要任務(wù)是追蹤下方介質(zhì)數(shù)據(jù)的組織位置和方式。我們可以把它想象成一名庫(kù)管理員,其通過(guò)自己的組織方案存儲(chǔ)和檢索標(biāo)注數(shù)據(jù)。常見的文件系統(tǒng)實(shí)現(xiàn)方式包括ext4、btrfs、XFS、F2FS和ZFS。也有很多其他方式。
下層稱作塊層。它是實(shí)際存儲(chǔ)硬件的抽象化表現(xiàn)。塊設(shè)備代表的是存儲(chǔ)設(shè)備或其中一部分。它看起來(lái)像一個(gè)大的可隨機(jī)訪問原始數(shù)據(jù)的連續(xù)區(qū)域,以塊的形式組織起來(lái),每個(gè)塊通常為512字節(jié)或4千字節(jié)。這些塊通過(guò)從0到數(shù)百萬(wàn)的塊編號(hào)訪問,具體取決于設(shè)備的整體大小。
這種抽象由不同的硬件驅(qū)動(dòng)程序?qū)崿F(xiàn)。對(duì)于有硬件閃存轉(zhuǎn)換層(FTL,經(jīng)常出現(xiàn)在eMMC、SSD和NVMe存儲(chǔ)設(shè)備中)的基于閃存的存儲(chǔ),這種驅(qū)動(dòng)程序可能會(huì)非常精簡(jiǎn)。FTL已經(jīng)完成了大部分抽象工作。適用于其他存儲(chǔ)形式的驅(qū)動(dòng)程序則可能比較復(fù)雜。
現(xiàn)在,大量不同的文件系統(tǒng)實(shí)現(xiàn)表明,它們?cè)谒俣?、可靠性和資源使用情況等性能指標(biāo)方面存在差異。這說(shuō)明,對(duì)于某個(gè)特定的用例,有些驅(qū)動(dòng)程序可能比其他類型更適用,那么該如何挑選合適的驅(qū)動(dòng)程序呢?通常,速度和資源的使用情況很容易測(cè)試,但由于現(xiàn)實(shí)中存在斷電等諸多問題,可靠性則不易測(cè)試。這里概述的測(cè)試設(shè)置可以幫助我們解決這個(gè)問題。
1.2 潛在故障模式
?
因意外斷電而受損是可寫文件系統(tǒng)的一個(gè)常見問題。通常,更改文件會(huì)導(dǎo)致文件系統(tǒng)向底層存儲(chǔ)介質(zhì)發(fā)出一個(gè)或多個(gè)寫入命令(通過(guò)塊層)。整個(gè)操作過(guò)程只有在所有命令全部執(zhí)行后才能完成。
如果意外斷電,磁盤中的數(shù)據(jù)可能只被部分寫入。根據(jù)介質(zhì)的特征,單次操作都可能中斷,導(dǎo)致運(yùn)行狀態(tài)不一致。
任何這種錯(cuò)誤都會(huì)以不同的方式體現(xiàn)在文件系統(tǒng)層中。根據(jù)中斷寫入操作的目的和位置,可能會(huì)出現(xiàn)數(shù)據(jù)(文件內(nèi)容)或元數(shù)據(jù)損壞(文件名稱、文件大小、目錄等)。元數(shù)據(jù)損壞的后果通常更嚴(yán)重。如果元數(shù)據(jù)受損,可能導(dǎo)致從文件名錯(cuò)誤到整個(gè)文件系統(tǒng)不可用等各種問題。元數(shù)據(jù)比較小,更容易通過(guò)冗余等方式減輕損害。通常防止數(shù)據(jù)損壞的措施成本較高,但它可以確保文件系統(tǒng)整體可用,即使存儲(chǔ)在某處的單個(gè)文件包含虛假數(shù)據(jù)也是如此。
1.3 現(xiàn)代文件系統(tǒng)使用的緩解策略
?
如上所述,可利用多種方法減輕或阻止上述損壞。比較常見的三種方法包括日志記錄、寫時(shí)復(fù)制(CoW)和日志結(jié)構(gòu)文件系統(tǒng)。
這些方法的選擇取決于數(shù)據(jù)冗余形式?;旧?,日志記錄會(huì)先將所有數(shù)據(jù)寫入占位符區(qū)域,然后復(fù)制到目標(biāo)位置。這樣,中斷后總有一份完整的先前數(shù)據(jù)或新寫入數(shù)據(jù),因而可恢復(fù)為一致的狀態(tài)。
寫時(shí)復(fù)制與此類似,其將新數(shù)據(jù)寫入未使用的位置,并標(biāo)記“被覆蓋”的數(shù)據(jù)。這種方法優(yōu)于日志記錄的地方在于無(wú)需回寫。它的缺點(diǎn)是經(jīng)常修改的文件會(huì)被碎片化。
日志結(jié)構(gòu)法則將所有內(nèi)容全部存儲(chǔ)到循環(huán)緩沖區(qū)中。這樣可以改善冗余和寫入性能,但需定期收集垃圾。備用電池等基于硬件的策略不考慮。
1.4 用例依賴嚴(yán)重程度
?
第1.2條所述的故障其嚴(yán)重程度取決于使用場(chǎng)景。
如果受損的文件系統(tǒng)是根文件系統(tǒng),ECU將無(wú)法運(yùn)行,需要更換或至少需由合格人員親自干預(yù)。
如果文件系統(tǒng)用于二次數(shù)據(jù)記錄或不太重要的配置,可考慮使用自動(dòng)修復(fù)策略,將文件系統(tǒng)重新格式化。情況最壞時(shí),可能導(dǎo)致系統(tǒng)恢復(fù)出廠設(shè)置。這是否可接受需在系統(tǒng)設(shè)計(jì)階段確定。
例如,我們可以考慮采用可調(diào)節(jié)乘坐艙空調(diào)和娛樂功能的系統(tǒng),而非直接啟動(dòng)車輛駕駛輔助的系統(tǒng)。前一種系統(tǒng)的短時(shí)功能失效以及某些個(gè)人設(shè)置失效可能會(huì)為我們帶來(lái)不便,但并不會(huì)為車輛駕駛員帶來(lái)危險(xiǎn)。后一種系統(tǒng)則不同。
其他需要考慮的因素包括當(dāng)前硬件冗余或自動(dòng)備份。同時(shí),根據(jù)文件系統(tǒng)的配置,可在可靠性、速度和閃存磨損之間進(jìn)行權(quán)衡。
2. 系統(tǒng)性文件系統(tǒng)斷電抗擾度測(cè)試
?
為收集有關(guān)文件系統(tǒng)電源故障可靠性的確鑿且可量化的證據(jù),我們進(jìn)行了確定性和文件系統(tǒng)不可知測(cè)試設(shè)置。在我們的測(cè)試中,文件系統(tǒng)為黑盒。此外,我們了解了下塊和上VFS層的概況。
2.1 想法
?
如上所述,任何斷電引起的文件系統(tǒng)損壞都是由于意外中斷導(dǎo)致的硬件層寫入操作所致。根據(jù)閃存硬件規(guī)格,我們知道較大規(guī)模的寫入操作由較小的增量組成,這些增量以原子方式寫入,也就是說(shuō)它們要么完全寫入,要么根本不寫入[1]–[3]。因此,如果硬件正確實(shí)現(xiàn)了原子性,則可以中斷寫入操作的狀態(tài)數(shù)量將是有限的。
也就是說(shuō),我們可以在一系列寫入操作期間每一個(gè)可能的時(shí)間點(diǎn)模擬斷電故障。每次中斷,測(cè)試文件系統(tǒng)都有一次恢復(fù)機(jī)會(huì)。然后,檢查是否出現(xiàn)任何故障模式。
2.2 方法論
?
圖2:dm-log-writes測(cè)試設(shè)置
Linux設(shè)備映射器的dm-log-writes軟件驅(qū)動(dòng)程序可執(zhí)行這些測(cè)試。它可以在文件系統(tǒng)和塊設(shè)備層之間記錄通過(guò)它的每一次寫入。所生成的二進(jìn)制寫日志將被寫入大容量持久性存儲(chǔ)器中,供后續(xù)回放。
為生成日志輸入,我們使用了Linux測(cè)試項(xiàng)目(ltp)中常見的fsstress程序[4]。給定一個(gè)隨機(jī)種子后,fsstress可根據(jù)預(yù)先設(shè)定的概率分布,通過(guò)VFS層在文件系統(tǒng)生成一組操作。然后,這些操作會(huì)使測(cè)試的黑盒文件系統(tǒng)向塊層發(fā)出寫入操作,被dm-log-writes攔截、記錄,然后中繼到存儲(chǔ)塊設(shè)備中。記錄的寫入操作路徑如上圖所示。
dm-log-writes二進(jìn)制日志的回放能夠達(dá)到數(shù)據(jù)塊設(shè)備在日志記錄期間可能經(jīng)歷的所有狀態(tài)。我們創(chuàng)建的回放實(shí)現(xiàn)能夠?qū)⒉糠秩罩緱l目回放到單個(gè)寫入塊(在多數(shù)基于閃存的硬件上均為原子塊)的粒度。所生成的塊設(shè)備快照會(huì)呈現(xiàn)存儲(chǔ)器在突然斷電后可能出現(xiàn)的所有狀態(tài)。
現(xiàn)在我們來(lái)檢查所有可能出現(xiàn)的斷電狀態(tài)。每一步我們都會(huì)詳細(xì)檢查VFS層,確認(rèn)文件系統(tǒng)是否仍然可用、一致,且未出現(xiàn)數(shù)據(jù)或元數(shù)據(jù)損壞。我們還會(huì)執(zhí)行檢查和其他寫入操作,搜索“隱藏的”損壞,這些損壞無(wú)法被通常的靜態(tài)文件系統(tǒng)檢查工具立即檢測(cè)出來(lái)。
2.3 完整性
?
我們對(duì)上述方法完整性的論證基于前述對(duì)一系列文件系統(tǒng)操作期間斷電可能導(dǎo)致的所有狀態(tài)的模擬。相關(guān)汽車級(jí)存儲(chǔ)介質(zhì)的硬件文檔表明,至少可以認(rèn)為單塊寫入是原子操作[3]、[5]。因此,如果我們對(duì)所有可能實(shí)施的原子步驟進(jìn)行測(cè)試,即逐塊寫入,我們的測(cè)試就磁盤數(shù)據(jù)的可達(dá)狀態(tài)而言就是完整的。
當(dāng)然,這只是問題的一部分。我們還需要將不同的操作集呈現(xiàn)為VFS層的輸入數(shù)據(jù)。這里,我們提出一個(gè)統(tǒng)計(jì)論點(diǎn),即在fsstress上使用不同的種子來(lái)確保所有可能的操作以不同的組合運(yùn)行。
3. 對(duì)客戶的價(jià)值
?
Elektrobit對(duì)相關(guān)基于Linux的產(chǎn)品采用這種測(cè)試方法來(lái)提高可靠性。結(jié)果可直接用于在開發(fā)期間制定與文件系統(tǒng)有關(guān)的設(shè)計(jì)決策。特定用例產(chǎn)生的問題可盡早發(fā)現(xiàn),盡早解決。
當(dāng)然,測(cè)試不會(huì)在產(chǎn)品發(fā)布后停止,而將在維護(hù)過(guò)程中繼續(xù)進(jìn)行以免實(shí)施回歸測(cè)試。特別是Linux內(nèi)核升級(jí)時(shí),如果在新的上游代碼中引入文件系統(tǒng)漏洞,將會(huì)產(chǎn)生額外的保護(hù)層。
除此之外,Elektrobit還能根據(jù)需要為特殊用例提供定制解決方案。他們能夠部署專門的測(cè)試設(shè)置,包括對(duì)在不同硬件、虛擬化或裸機(jī)上運(yùn)行的不同Linux設(shè)置上的不同文件系統(tǒng)集進(jìn)行結(jié)果評(píng)估。
4. emlix
?
emlix提供工業(yè)級(jí)Linux,用于在整個(gè)產(chǎn)品生命周期內(nèi)實(shí)現(xiàn)設(shè)備、機(jī)器和工廠的數(shù)字化和安全聯(lián)網(wǎng)。
20多年來(lái),emlix一直在將系統(tǒng)知識(shí)、開源世界的創(chuàng)新和市場(chǎng)知識(shí)傳輸?shù)轿覀?50多家客戶的產(chǎn)品中,這些客戶遍及汽車、能源工業(yè)、自動(dòng)化技術(shù)、醫(yī)療技術(shù)、安全技術(shù)等領(lǐng)域。
作為一家專業(yè)的開源軟件提供商,我們確保整個(gè)流程安全、透明。我們使用的工具和開發(fā)標(biāo)準(zhǔn)能夠滿足工業(yè)要求和認(rèn)證需要。我們?yōu)槲覀兊慕鉀Q方案提供長(zhǎng)期維護(hù)合同,對(duì)產(chǎn)品生命周期和客戶投資負(fù)責(zé)。
參考文獻(xiàn)
?
[1]?NVM Express Inc., “NVM Command Set Specification 1.0b.” Dec.18,2021.[Online].Available: https://nvmexpress.org/developers/nvme-specification/
[2]?JEDEC, “JESD84-B51 - Embedded Multi-Media Card (e?MMC) Electrical Standard (5.1).”Jul. 2014.
[3]?Micron Technology Inc., “TN-FC-27: e-MMC Power Loss Data Integrity.”Dec. 2013.
[4]? “Linux Test Project - fsstress.” Silicon Graphics Inc. [Online].Available:
https://github.com/linux-test-project/ltp/tree/master/testcases/kernel/fs/fsstress
[5]?Micron Technology Inc., “e.MMC Memory - MTFC8GAM, MTFC16GAP, MTFC32GAP, MTFC64GAP, MTFC128GAP.”O(jiān)ct. 2018.
關(guān)于作者
?
Andreas Zdziarstek
emlix GmbH
Andreas Zdziarstek是emlix GmbH的一名系統(tǒng)工程師。他主要從事嵌入式Linux軟件方面的工作,為汽車領(lǐng)域的用例開發(fā)定制解決方案,重點(diǎn)解決問題包括安全性、可靠性和可用性。
Thomas Brinker
emlix GmbH
Thomas Brinker是emlix GmbH的一名高級(jí)系統(tǒng)工程師和項(xiàng)目經(jīng)理。他是汽車、醫(yī)療、工業(yè)和消費(fèi)設(shè)備領(lǐng)域的安全嵌入式Linux系統(tǒng)架構(gòu)師,在整個(gè)產(chǎn)品生命周期中負(fù)責(zé)需求工程和設(shè)計(jì)。
編輯:黃飛
?
評(píng)論