2009-01-26 67 views
3

我們有許多嵌入式系統需要通過塊設備模擬來訪問駐留在閃存上的文件系統。我們最早的平臺運行在緊湊型閃存上,並且這些系統已經使用了3年多,沒有在啓動期間運行單個fsck,並且到目前爲止我們沒有歸因於文件系統或CF的故障。我應該在嵌入式系統上使用ext3嗎?

在我們最新的平臺上,我們使用USB-flash進行初始生產,現在正在遷移到磁盤模塊以存儲r/w。前段時間,我們在USB存儲設備上運行的很多設備上都遇到了文件系統問題,所以我啓用了e2fsck以查看是否有幫助。事實證明,我們收到了一批不好的閃存,所以一旦更換了這些問題,問題就消失了。自從我們沒有任何跡象表明它使系統更加可靠並且歷史上我們在沒有它的情況下一直沒有問題以來,我一直禁用e2fsck。

既然我們已經開始放入磁盤模塊單元,我已經開始再次看到文件系統錯誤。突然系統無法讀取/寫入某些文件,如果我試圖從緊急控制檯訪問文件,我只會得到「輸入/輸出錯誤」。我再次啓用了e2fsck,並且所有文件都已更正。

O'Reilly的「構建嵌入式Linux系統」建議運行的e2fsck使用在ext2文件系統,但沒有提到它相對於ext3的,所以我有點困惑,以我是否應啓用與否。

你在嵌入式系統上運行fsck需要什麼?我們正在考慮將二進制文件放在ar/o分區上,並且只考慮在同一閃存設備上的ar/w分區上修改的文件,以便fsck永遠不會意外刪除重要的系統二進制文件,是否有人有過使用這種設置的經驗(好壞)?

回答

4

我認爲您的問題的答案更多地涉及您的應用程序相對於其數據的一致性要求類型。也就是說,如果在沒有正式關閉系統的情況下斷電,必須保證什麼?通常,在應用程序中的關鍵事務點處,沒有特定應用程序關閉/同步文件和刷新磁盤緩存等,桌面操作系統類型文件系統都無法處理這一切,以確保您需要維護的內容在事實上致力於媒體。

運行fsck修復了文件系統,但沒有上述照顧,不能保證您所做的更改實際上會保留。即:由於電源故障,您將失去什麼不完全確定性。

我同意將您的二進制文件或其他重要的只讀數據放在一個單獨的只讀分區確實有助於確保它們不會因文件系統結構的fsck更正而錯誤地丟失。至少,把它們放在不同於保存R/W數據的根目錄下的子目錄將會有所幫助。但是在這兩種情況下,如果您支持軟件更新,您仍然需要有方案來處理編寫「只讀」區域的問題。

在我們的應用程序中,我們實際上保留了一對類似於二進制文件的目錄,並且系統設置爲從兩個區域中的任意一個啓動。在軟件更新期間,我們更新第一個目錄,將所有內容同步到介質,並在轉到第二個副本的更新之前驗證磁盤上的MD5校驗和。在啓動時,只有在MD5校驗和良好的情況下才會使用它們。這可確保始終啓動連貫的映像。

+0

其實我們已經有很少的目錄,這些目錄很少被寫入像fsck像/ lib/modules(!)一樣被刪除。我喜歡你的雙分區設置,我想在這裏實現類似的東西,但管理層給它的優先級很低。 – 2009-01-26 14:50:55

+0

@David - 是的,刪除是可能的,如果修改。 fsck所做的並不理想,甚至有可能導致它折騰得比應該/可能更多的bug。它修復了文件系統的完整性,但它也是以犧牲一些數據爲代價的。 – 2009-01-26 14:58:31

2

戴夫,

我總是推薦了一些重新啓動後運行fsck的,但不是每一次。

原因是,ext3是journal-ed。因此,除非您啓用回寫(無日誌),否則大多數情況下,您的元數據/文件系統表應與您的數據(文件)保持同步。

但是就像Jeff所說的那樣,它並不能保證文件系統上方的圖層。這意味着,您仍然會收到「損壞」的文件,因爲有些記錄可能沒有寫入文件系統。

我不確定你正在運行什麼嵌入式設備,但它多久重新啓動一次? 如果是重新啓動控制,則可以在重新啓動之前始終進行「同步;同步;同步」。

我一直在使用CF自己多年,非常罕見的場合我得到了文件系統錯誤。 fsck確實對這種情況有所幫助。

關於分離你的分區,我懷疑它的優點。對於文件系統上的每個數據/文件,都有一個與其關聯的元數據。大多數情況下,如果您不更改文件,例如。二進制/系統文件,那麼這個元數據不應該改變。除非你有錯誤的硬件,比如說讀寫&,那麼這些只讀文件應該是安全的。

當你有一些可寫的東西時,大多數問題都會出現,無論你把它放在哪裏,如果應用程序處理不好,它可能會導致問題。

希望有所幫助。