摘要：設計一種能夠在典型嵌入式環境下應用的線性文件系統，為嵌入式系統Flash空間的管理提供一種非常有效的手段。它包裝和通用文件系統類似的API接口，設計的實現獨立于實時操作系統（RTOS）和具體的Flash典型，可方便移植到不同的嵌入式應用中。

在嵌入式系統中，為了便于對閃存（Flash）空間進行管理，會采用文件的形式來訪問Flash。目前，可以購買到的Flash文件系統一般都是兼容DOS的文件系統（Flash File System，FFS），這對需要一個具有復雜的目錄層次，并且DDS文件兼容的系統來說是必要的；但是對大多數的嵌入式應用來說，這種文件系統太過奢侈。筆者在參與嵌入式系統項目的時候，設計了一種線性文件系統，它適用于大多數的嵌入式應用對Flash文件系統的需求。

線性文件系統設計基于三個目標：一是提供給應用程序通過文件名而不是物理地址訪問系統Flash的能力；二是文件系統的設計獨立于實時操作系統（RTOS），這樣可以很容易移植到不同的嵌入式應用中；三是設計統一的底層接口，適應不同的Flash類型。本文設計的線性文件系統為典型的嵌入式系統提供了所需的類文件系統能力。需要注意的是，本文件系統不支持復雜的Flash扇區擦寫次數均衡算法，沒有目錄層次，并且和其它的文件系統不兼容。

1 線性文件系統

線性文件系統的設計思路是這樣的：文件分為文件頭和文件數據區兩個部分，每個文件按照順序存放在Flash中，以單向鏈表來鏈接文件。文件的起始部分是文件頭，包含文件的屬性、指向下一個文件頭的指針、文件頭和文件數據區的32位循環冗余校驗和（CRC32）等。文件頭用一個32位的字來表示文件屬性，每位表示一種屬性，如數據文件或者是可執行文件，是否已刪除的文件等，具體可以根據應用的需要來定義文件的屬性；文件頭和文件數據區維護獨立的CRC32校驗，使文件系統能更精確檢測文件的完整性。文件的起始地址沒有特殊需求，分配給文件系統的Flash大小限制了文件的大小。另外，線性文件系統作為嵌入式系統的一個功能模塊，它為應用程序提供與標準文件系統類似的API接口，如：read()、write()、open（）、close()、stat()和seek（）等。對于同時在多片Flash的系統而言，每片Flash相當于一個目標，文件都可存儲在任何一片中（當然受物理空間限制），但不能跨片存儲。

電池備份的RAM來替換空閑扇區，可以增加Flash的整體壽命，但是對那些預算緊張的應用來說太過奢移。

具體的碎片整理過程是，首先建立碎片整理區。①為每個扇區建立2個CRC32表項；第一個CRC32是這個扇區在碎片整理前的CRC值；第二個CRC32值是計算出來的碎片整理后的CRC32值。這些CRC是當碎片整理過程被打斷時，用來重新恢復整理用的。②創建碎片整理文件頭信息表，每個活動的文件占用一個表項。③計算①和②的CRC值，并保存。①～③的數據保存在圖1中的碎片整理記錄區。第二步是文件重定位；遍歷文件系統的每個扇區，處理重新定位后存儲空間和該扇區相覆蓋的文件。在每個扇區被重寫之前，扇區原來的信息被保存在空閑扇區里。第三步，擦除Flash；遍歷未使用的扇區，確認所有的扇區被刪除。第四步，完整性檢測：對新的文件進行檢測，保證所有重定位的文件都是完整的。

3 應用分析

Flash的扇區有最大擦寫次數。當前的Flash芯片一般支持10萬～100萬次的擦除。文件系統的應用各不相同，所以這里不能下結論說采用線性文件系統Flash的壽命會有多長。下面解釋文件系統訪問Flash的方法。這樣用戶可以根據應用來判斷Flash的預期壽命。

我們所設計的線性文件系統并不進行扇區刪除次數均衡，以延長Flash的使用壽命。如果所需要的文件系統頻繁修改并需要扇區刪除次數均衡，可以購買現成的Flash文件系統。扇區刪除均衡算法大大增加了底層實現的復雜性，并且超出本文的討論范圍。一般來說，通過文件系統來管理Flash的需求遠大于對Flash扇區擦寫次數均衡的需求，特別是現在越來越多的Flash扇區都支持100萬次的擦寫。

如上面所提到的，文件系統本身提供給編程者的接口API與標準OS提供的接口類似。這可能誤導開發者認為文件系統可以看作是一個硬盤，以任意的頻率進行讀寫操作。事實并不是這樣，線性文件系統碎片整理同制并沒有進行擦寫次數均衡，這意味著空閑扇區可能會是最早損壞的Flash扇區。因為在碎片整理過程中，空閑扇區被用作其它所有扇區的暫時存放扇區。例如在設計里，有13個扇區Flash用來作線性文件系統區，有1個扇區作為空閑扇區。假設對于最壞情況的碎片整理（13個扇區都影響到），如果每天進行1次碎片整理，對于100 000次擦寫次數的Flash而言，可用期能夠超過20年（100 000/13/365=21）。20年是基于每