1.文件系統斷電可靠性問題
?
“一切皆是文件”,這是Linux生態系統中最常被引用的經驗法則之一。這體現了文件以及文件系統可靠性對Linux操作系統的重要性。
提高可靠性最簡單的方法就是把文件系統設置為只讀狀態。即禁止對其中的內容作任何修改。這樣,文件系統便不會因寫入操作期間發生故障而受損。當然,您也可以不這么做。配置數據、日志文件、臨時信息及其他數據需要一個可靠的可寫文件系統。
圖1:Linux內核中的文件系統
考慮到汽車應用的獨特需求,斷電時確保系統的可靠性非常重要。汽車嵌入式系統面臨兩種高風險:意外失電以及意外失電時處理不當導致功能失效。顯然,我們都不希望自己的汽車因電池電量不足而被拖到維修門店。
1.1. ?背景 — 到底什么是“文件系統”?
?
對于Linux設置,無論是嵌入式還是桌面設置,文件系統層都是持久性和易失性存儲器的核心。如圖1所示,當某項應用想與系統中的數據交互時,可通過虛擬文件系統或VFS實現。
VFS層可抽象出底層文件系統實現的差異。事實上,我們在與文件交互時經常會看到向上呈現的現象,例如“/home/user/myfile.txt”。
實際文件系統實現發生在VFS下。它的主要任務是追蹤下方介質數據的組織位置和方式。我們可以把它想象成一名庫管理員,其通過自己的組織方案存儲和檢索標注數據。常見的文件系統實現方式包括ext4、btrfs、XFS、F2FS和ZFS。也有很多其他方式。
下層稱作塊層。它是實際存儲硬件的抽象化表現。塊設備代表的是存儲設備或其中一部分。它看起來像一個大的可隨機訪問原始數據的連續區域,以塊的形式組織起來,每個塊通常為512字節或4千字節。這些塊通過從0到數百萬的塊編號訪問,具體取決于設備的整體大小。
這種抽象由不同的硬件驅動程序實現。對于有硬件閃存轉換層(FTL,經常出現在eMMC、SSD和NVMe存儲設備中)的基于閃存的存儲,這種驅動程序可能會非常精簡。FTL已經完成了大部分抽象工作。適用于其他存儲形式的驅動程序則可能比較復雜。
現在,大量不同的文件系統實現表明,它們在速度、可靠性和資源使用情況等性能指標方面存在差異。這說明,對于某個特定的用例,有些驅動程序可能比其他類型更適用,那么該如何挑選合適的驅動程序呢?通常,速度和資源的使用情況很容易測試,但由于現實中存在斷電等諸多問題,可靠性則不易測試。這里概述的測試設置可以幫助我們解決這個問題。
1.2 潛在故障模式
?
因意外斷電而受損是可寫文件系統的一個常見問題。通常,更改文件會導致文件系統向底層存儲介質發出一個或多個寫入命令(通過塊層)。整個操作過程只有在所有命令全部執行后才能完成。
如果意外斷電,磁盤中的數據可能只被部分寫入。根據介質的特征,單次操作都可能中斷,導致運行狀態不一致。
任何這種錯誤都會以不同的方式體現在文件系統層中。根據中斷寫入操作的目的和位置,可能會出現數據(文件內容)或元數據損壞(文件名稱、文件大小、目錄等)。元數據損壞的后果通常更嚴重。如果元數據受損,可能導致從文件名錯誤到整個文件系統不可用等各種問題。元數據比較小,更容易通過冗余等方式減輕損害。通常防止數據損壞的措施成本較高,但它可以確保文件系統整體可用,即使存儲在某處的單個文件包含虛假數據也是如此。
1.3 現代文件系統使用的緩解策略
?
如上所述,可利用多種方法減輕或阻止上述損壞。比較常見的三種方法包括日志記錄、寫時復制(CoW)和日志結構文件系統。
這些方法的選擇取決于數據冗余形式。基本上,日志記錄會先將所有數據寫入占位符區域,然后復制到目標位置。這樣,中斷后總有一份完整的先前數據或新寫入數據,因而可恢復為一致的狀態。
寫時復制與此類似,其將新數據寫入未使用的位置,并標記“被覆蓋”的數據。這種方法優于日志記錄的地方在于無需回寫。它的缺點是經常修改的文件會被碎片化。
日志結構法則將所有內容全部存儲到循環緩沖區中。這樣可以改善冗余和寫入性能,但需定期收集垃圾。備用電池等基于硬件的策略不考慮。
1.4 用例依賴嚴重程度
?
第1.2條所述的故障其嚴重程度取決于使用場景。
如果受損的文件系統是根文件系統,ECU將無法運行,需要更換或至少需由合格人員親自干預。
如果文件系統用于二次數據記錄或不太重要的配置,可考慮使用自動修復策略,將文件系統重新格式化。情況最壞時,可能導致系統恢復出廠設置。這是否可接受需在系統設計階段確定。
例如,我們可以考慮采用可調節乘坐艙空調和娛樂功能的系統,而非直接啟動車輛駕駛輔助的系統。前一種系統的短時功能失效以及某些個人設置失效可能會為我們帶來不便,但并不會為車輛駕駛員帶來危險。后一種系統則不同。
其他需要考慮的因素包括當前硬件冗余或自動備份。同時,根據文件系統的配置,可在可靠性、速度和閃存磨損之間進行權衡。
2. 系統性文件系統斷電抗擾度測試
?
為收集有關文件系統電源故障可靠性的確鑿且可量化的證據,我們進行了確定性和文件系統不可知測試設置。在我們的測試中,文件系統為黑盒。此外,我們了解了下塊和上VFS層的概況。
2.1 想法
?
如上所述,任何斷電引起的文件系統損壞都是由于意外中斷導致的硬件層寫入操作所致。根據閃存硬件規格,我們知道較大規模的寫入操作由較小的增量組成,這些增量以原子方式寫入,也就是說它們要么完全寫入,要么根本不寫入[1]–[3]。因此,如果硬件正確實現了原子性,則可以中斷寫入操作的狀態數量將是有限的。
也就是說,我們可以在一系列寫入操作期間每一個可能的時間點模擬斷電故障。每次中斷,測試文件系統都有一次恢復機會。然后,檢查是否出現任何故障模式。
2.2 方法論
?
圖2:dm-log-writes測試設置
Linux設備映射器的dm-log-writes軟件驅動程序可執行這些測試。它可以在文件系統和塊設備層之間記錄通過它的每一次寫入。所生成的二進制寫日志將被寫入大容量持久性存儲器中,供后續回放。
為生成日志輸入,我們使用了Linux測試項目(ltp)中常見的fsstress程序[4]。給定一個隨機種子后,fsstress可根據預先設定的概率分布,通過VFS層在文件系統生成一組操作。然后,這些操作會使測試的黑盒文件系統向塊層發出寫入操作,被dm-log-writes攔截、記錄,然后中繼到存儲塊設備中。記錄的寫入操作路徑如上圖所示。
dm-log-writes二進制日志的回放能夠達到數據塊設備在日志記錄期間可能經歷的所有狀態。我們創建的回放實現能夠將部分日志條目回放到單個寫入塊(在多數基于閃存的硬件上均為原子塊)的粒度。所生成的塊設備快照會呈現存儲器在突然斷電后可能出現的所有狀態。
現在我們來檢查所有可能出現的斷電狀態。每一步我們都會詳細檢查VFS層,確認文件系統是否仍然可用、一致,且未出現數據或元數據損壞。我們還會執行檢查和其他寫入操作,搜索“隱藏的”損壞,這些損壞無法被通常的靜態文件系統檢查工具立即檢測出來。
2.3 完整性
?
我們對上述方法完整性的論證基于前述對一系列文件系統操作期間斷電可能導致的所有狀態的模擬。相關汽車級存儲介質的硬件文檔表明,至少可以認為單塊寫入是原子操作[3]、[5]。因此,如果我們對所有可能實施的原子步驟進行測試,即逐塊寫入,我們的測試就磁盤數據的可達狀態而言就是完整的。
當然,這只是問題的一部分。我們還需要將不同的操作集呈現為VFS層的輸入數據。這里,我們提出一個統計論點,即在fsstress上使用不同的種子來確保所有可能的操作以不同的組合運行。
3. 對客戶的價值
?
Elektrobit對相關基于Linux的產品采用這種測試方法來提高可靠性。結果可直接用于在開發期間制定與文件系統有關的設計決策。特定用例產生的問題可盡早發現,盡早解決。
當然,測試不會在產品發布后停止,而將在維護過程中繼續進行以免實施回歸測試。特別是Linux內核升級時,如果在新的上游代碼中引入文件系統漏洞,將會產生額外的保護層。
除此之外,Elektrobit還能根據需要為特殊用例提供定制解決方案。他們能夠部署專門的測試設置,包括對在不同硬件、虛擬化或裸機上運行的不同Linux設置上的不同文件系統集進行結果評估。
4. emlix
?
emlix提供工業級Linux,用于在整個產品生命周期內實現設備、機器和工廠的數字化和安全聯網。
20多年來,emlix一直在將系統知識、開源世界的創新和市場知識傳輸到我們350多家客戶的產品中,這些客戶遍及汽車、能源工業、自動化技術、醫療技術、安全技術等領域。
作為一家專業的開源軟件提供商,我們確保整個流程安全、透明。我們使用的工具和開發標準能夠滿足工業要求和認證需要。我們為我們的解決方案提供長期維護合同,對產品生命周期和客戶投資負責。
參考文獻
?
[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.”Oct. 2018.
關于作者
?
Andreas Zdziarstek
emlix GmbH
Andreas Zdziarstek是emlix GmbH的一名系統工程師。他主要從事嵌入式Linux軟件方面的工作,為汽車領域的用例開發定制解決方案,重點解決問題包括安全性、可靠性和可用性。
Thomas Brinker
emlix GmbH
Thomas Brinker是emlix GmbH的一名高級系統工程師和項目經理。他是汽車、醫療、工業和消費設備領域的安全嵌入式Linux系統架構師,在整個產品生命周期中負責需求工程和設計。
編輯:黃飛
?
評論
查看更多