STANAG-4575文件系統(tǒng)在VXWorks上的實現(xiàn)

王 健，李小勇

0 引言

飛機在一次飛行過程中，需要對機載采集卡上采集的各項參數(shù)進行記錄，如發(fā)動機參數(shù)，音頻數(shù)據(jù)和視頻數(shù)據(jù)等。這些數(shù)據(jù)的采集、存儲和處理，為進行飛行事故征候分析、故障診斷、視情維修、飛行品質(zhì)監(jiān)控、試飛監(jiān)控等提供了豐富信息。然而，由于缺少統(tǒng)一的數(shù)據(jù)記錄和存儲標準，不利于數(shù)據(jù)的分析和共享。1994年，美國靶場司令委員會（RCC）決定不再要求統(tǒng)一的記錄介質(zhì)的格式，而是定義統(tǒng)一的數(shù)據(jù)格式，形成大家公認的數(shù)據(jù)接口。2004年5月，RCC對IRIG 106第十章進行修改，提出了固態(tài)記錄標準。通過RCC，廠商和用戶多年共同努力，2007年2月，IRIG 106第十章被修改為：數(shù)字記錄標準。目前，IRIG數(shù)字記錄標準已成為國際公認標準之一。

IRIG 106第十章采用STANAG-4575文件系統(tǒng)作為數(shù)據(jù)存儲方式。STANAG-4575文件系統(tǒng)是北大西洋公約組織（NATO）制定的可卸載記錄模塊上的數(shù)據(jù)存儲標準。之所以選擇該文件系統(tǒng)，是因為它對記錄中的順序?qū)懖僮鬟M行了優(yōu)化。同時，STANAG-4575文件系統(tǒng)的元數(shù)據(jù)開銷很小，并且可以支持很大的文件（64位）。選擇該標準文件系統(tǒng)的另一個優(yōu)勢是它可以保證記錄數(shù)據(jù)可以向前或向后兼容。

在飛機的記錄設備中，通常采用VXWorks操作系統(tǒng)。VXWorks是美國風河公司（WindRiver）開發(fā)的嵌入式實時操作系統(tǒng)。它憑借良好的可靠性和卓越實時性在嵌入式實時操作系統(tǒng)領域占據(jù)重要地位。它被廣泛地應用在通信、軍事、航空、航天等高精尖及實時性要求極高的領域中，如衛(wèi)星通訊、軍事演習、彈道制導、飛機導航等。在美國火星探測器“勇氣號”和“機遇號”均采用VXWorks作為其操作系統(tǒng)。

VXWorks下層采用與FAT文件系統(tǒng)相兼容的dosFs作為其本地文件系統(tǒng)，該文件系統(tǒng)的主要問題有：

1) 單個文件最大只有 4GB，隨著磁盤容量的增加以及對記錄高清視頻數(shù)據(jù)的需要，這個限制會嚴重影響上層記錄軟件的實現(xiàn)；

2) 長時間的記錄過程可能會導致文件系統(tǒng)的碎片增加，使磁盤記錄性能嚴重下降；

3) 在出現(xiàn)意外斷電等情況時，文件系統(tǒng)可能整個被破壞，導致文件數(shù)據(jù)無法恢復；

因此，我們在VXWorks上實現(xiàn)了STANAG-4575文件系統(tǒng)，來解決上面這些問題。該實現(xiàn)主要的優(yōu)點包括：

1) 通過對關(guān)鍵元數(shù)據(jù)信息進行備份和校驗，提高了系統(tǒng)的可靠性；

2) 通過哈希表等數(shù)據(jù)結(jié)構(gòu)來管理文件系統(tǒng)的元數(shù)據(jù)，提高了系統(tǒng)的性能；

3) 通過既遵循標準，又靈活變通的實現(xiàn)來提高系統(tǒng)的性能和可靠性；

4) 通過控制元數(shù)據(jù)和數(shù)據(jù)的寫入方式來保證數(shù)據(jù)在磁盤上的一致性。

1 背景介紹

1.1. STANAG-4575文件系統(tǒng)介紹

STANAG-4575文件系統(tǒng)是北大西洋公約組織（NATO）為可卸載記錄模塊（如固態(tài)硬盤）制定的數(shù)據(jù)存儲標準。通過引入該標準，IRIG 106可以讓記錄數(shù)據(jù)不依賴于下層設備，并且可以保證記錄數(shù)據(jù)向前和向后的兼容性。

STANAG-4575文件結(jié)構(gòu)定義所規(guī)定的文件系統(tǒng)格式，如圖1所示：

圖1 文件系統(tǒng)結(jié)構(gòu)

如圖1所示，除邏輯磁盤塊0保留之外，其他的邏輯塊包括兩種類型，一種是目錄塊，用來存放文件的元數(shù)據(jù)，另一種是數(shù)據(jù)塊，用來存放文件的數(shù)據(jù)。

該文件結(jié)構(gòu)定義規(guī)定，邏輯塊1必須為一個目錄塊，其他的目錄塊通過雙向鏈表方式（前向鏈表和后向鏈表）連接起來。

一個目錄塊的頭部 64字節(jié)包括該目錄塊的元數(shù)據(jù)信息，接著為該目錄塊中包含的文件項（File Entry）數(shù)組。每個文件項占用112字節(jié)，包含了文件的元數(shù)據(jù)信息，主要有：文件名、文件創(chuàng)建時間、文件大小、文件數(shù)據(jù)的起始塊地址、文件數(shù)據(jù)占用磁盤塊數(shù)和文件關(guān)閉時間。

文件的數(shù)據(jù)部分用來存放上層用戶的數(shù)據(jù)，對于訪問文件系統(tǒng)的接口來說，文件數(shù)據(jù)必須呈現(xiàn)邏輯上連續(xù)存放的方式。即，若文件數(shù)據(jù)所在的第一個磁盤塊為X，那用戶可以通過訪問磁盤塊X+1、X+2來訪問文件之后的數(shù)據(jù)。

將文件數(shù)據(jù)連續(xù)存放的好處是可以優(yōu)化文件的順序讀寫性能。同時，這種方式可以減少文件的元數(shù)據(jù)，即每個文件只要通過文件數(shù)據(jù)起始塊號、文件數(shù)據(jù)占用塊數(shù)量兩個值，就可以確定文件數(shù)據(jù)所占用的所有磁盤塊的位置。

1.2. VXWorks文件系統(tǒng)框架介紹

為了將STANAG-4575文件系統(tǒng)嵌入到VXWorks中，必須先了解VXWorks文件系統(tǒng)的框架。

VXWorks文件系統(tǒng)框架從上到下主要分為4層，分別為：

1) 虛擬文件系統(tǒng)層

2) 特定文件系統(tǒng)層

3) 磁盤緩存

4) 塊設備層

該文件系統(tǒng)的層次結(jié)構(gòu)，如圖2所示：

圖2 VXWorks文件系統(tǒng)層次架構(gòu)

從應用程序發(fā)來的請求，經(jīng)過虛擬文件系統(tǒng)層的解析，會將請求進一步傳向下層的特定文件系統(tǒng)層。下層的文件系統(tǒng)處理完請求后，將結(jié)果返回給虛擬文件系統(tǒng)層，虛擬文件系統(tǒng)再將結(jié)果返回給應用程序。

特定的文件系統(tǒng)要對磁盤塊設備進行管理，它需要經(jīng)常對磁盤進行讀寫操作。由于磁盤設備的讀寫速度和內(nèi)存相比較低，若文件系統(tǒng)的每次讀寫操作都在磁盤上進行，則磁盤會成為整個系統(tǒng)的瓶頸。因此，需要在文件系統(tǒng)和下層磁盤之間插入一級磁盤緩存，該磁盤緩存是內(nèi)存中的一塊區(qū)域，主要用來對磁盤的數(shù)據(jù)進行緩存。文件系統(tǒng)通常的讀寫操作都在磁盤緩存中進行。

磁盤緩存主要負責和下層真正的磁盤塊設備進行交互。它負責從磁盤設備中讀取數(shù)據(jù)，并將緩存中臟（DIRTY）的數(shù)據(jù)定期寫到磁盤上。同時，上層的文件系統(tǒng)也可以通過調(diào)用磁盤緩存提供的FLUSH函數(shù)將臟數(shù)據(jù)寫到磁盤上。

由于實現(xiàn)文件系統(tǒng)的主要工作是與上層的虛擬文件系統(tǒng)進行交互，因此需要對VXWorks虛擬文件系統(tǒng)層進行更進一步的分析。

VXWorks虛擬文件系統(tǒng)層的主要作用類似于Linux中的VFS，負責給上層應用提供統(tǒng)一的文件系統(tǒng)的接口。它將所有的對文件系統(tǒng)的操作都抽象為以下7個操作：

1) 創(chuàng)建文件（CREATE）

2) 刪除文件（DELETE）

3) 打開文件（OPEN）

4) 讀文件（READ）

5) 寫文件（WRITE）

6) 關(guān)閉文件（CLOSE）

7) 輸入輸出控制（IOCTL）

所有特定文件系統(tǒng)的擴展命令，都要通過調(diào)用IOCTL來實現(xiàn)。

虛擬文件系統(tǒng)為了能將上層發(fā)來的請求轉(zhuǎn)化為對下層文件系統(tǒng)的調(diào)用，就需要知道下層文件系統(tǒng)相關(guān)函數(shù)的具體實現(xiàn)。在VXWorks中，每個文件系統(tǒng)都必須有一個初始化函數(shù)，在該初始化函數(shù)中，需要將自己實現(xiàn)函數(shù)的指針注冊到虛擬文件系統(tǒng)中去。因此，要在VXWorks中嵌入自己的文件系統(tǒng)，實際上就是為該文件系統(tǒng)實現(xiàn)對應于 VXWorks虛擬文件系統(tǒng)的7個函數(shù)及相關(guān)輔助函數(shù)。

2 STANAG-4575實現(xiàn)框架介紹

該部分詳細描述STANAG-4575文件系統(tǒng)在VXWorks上的實現(xiàn)。首先介紹磁盤格式，接下來詳細描述在內(nèi)存中用到的數(shù)據(jù)結(jié)構(gòu)以及數(shù)據(jù)結(jié)構(gòu)的組織方式。

2.1 磁盤結(jié)構(gòu)

在文件系統(tǒng)磁盤結(jié)構(gòu)的設計過程中，主要有兩個因素需要考慮：

1) 必須嚴格遵照 STANAG-4575文件系統(tǒng)對磁盤格式的規(guī)定；

2) 在因素 1的基礎上，要盡量采用一種磁盤結(jié)構(gòu)，使得上層的文件系統(tǒng)可以可靠、穩(wěn)定、高效地實現(xiàn)。

首先，STANAG-4575將磁盤塊0保留，因此，用該磁盤塊來作為文件系統(tǒng)的超級塊。超級塊用來存放該磁盤塊設備的總體信息，包括塊設備名稱、磁盤塊大小，磁盤塊數(shù)量等等。另外，在其中還存放了目錄區(qū)和數(shù)據(jù)區(qū)的相關(guān)信息。最后，在超級塊的末尾，存放了超級塊中所有字段的 MD5校驗和，用來在磁盤塊掛載的時候檢查對超級塊的完整性進行檢驗。

由于超級塊是文件系統(tǒng)中最重要的數(shù)據(jù)結(jié)構(gòu)，因此除了對它做MD5校驗之外，還必須對其做冗余備份。將備份超級塊存放在最后一個磁盤塊上。這樣，即使主超級塊損壞，依然可以從最后一個磁盤塊上讀出文件系統(tǒng)的備份超級塊。

其次，STANAG-4575規(guī)定了磁盤塊1必須作為第一個目錄塊，且多個目錄塊之間用雙向鏈表連接。為了實現(xiàn)簡單高效，且保證文件系統(tǒng)的可靠性。將文件系統(tǒng)的所有目錄塊連續(xù)存放，即就是在整個磁盤塊的頭部連續(xù)地存放目錄塊信息，當然，目錄塊按照標準規(guī)定依然要采用鏈表來連接，只是此時可以順序地對目錄塊進行訪問。

采取這種做法的好處有：

1) 目錄塊連續(xù)存放，可以提高目錄區(qū)連續(xù)讀寫操作的性能，因為在文件系統(tǒng)掛載時，需要將所有目錄塊讀出，并在內(nèi)存中建立必要的數(shù)據(jù)結(jié)構(gòu)；

2) 即使目錄區(qū)鏈表出現(xiàn)錯誤，由于目錄在磁盤上位置固定，依然可以找到所有目錄塊；

這樣做法的問題是，文件系統(tǒng)的靈活性降低，即當文件數(shù)量很多，超過目錄區(qū)域的上限時，系統(tǒng)便不能再創(chuàng)建新的文件?？梢酝ㄟ^擴大目錄區(qū)域的數(shù)量來解決該問題。在實際中，創(chuàng)建 100,000個文件所需要的目錄塊區(qū)域僅僅占用10MB的空間。

同時，為了進一步提高文件系統(tǒng)的可靠性，對文件系統(tǒng)的目錄區(qū)也進行了備份操作。即，在整個磁盤的末尾，存放了備份目錄區(qū)。這樣，當主目錄區(qū)訪問出錯時，可以直接訪問備份目錄區(qū)。

最后，磁盤的其他部分都為數(shù)據(jù)區(qū)域。數(shù)據(jù)區(qū)域通過3個指針來管理，分別是指向數(shù)據(jù)區(qū)開始位置的指針、指向數(shù)據(jù)區(qū)結(jié)束位置的指針和指向數(shù)據(jù)區(qū)當前使用位置的指針。這種管理方式簡單高效，避免了通常的采用位圖方式來管理磁盤塊的低效和不可靠。該方式管理磁盤塊的具體過程會在下文中描述，磁盤塊的結(jié)構(gòu)，如圖3所示：

圖3 文件系統(tǒng)磁盤結(jié)構(gòu)

2.2 內(nèi)存中的數(shù)據(jù)結(jié)構(gòu)

在VXWorks文件系統(tǒng)框架中，每個已掛載的塊設備由塊設備描述符來管理。塊設備描述符的第一個字段為一個DEV_HDR類型的結(jié)構(gòu)體，VXWorks的虛擬文件系統(tǒng)層通過該結(jié)構(gòu)體來實現(xiàn)對所有已掛載的塊設備的組織和管理。塊設備描述符的其余字段由各個文件系統(tǒng)的實現(xiàn)來定義。

塊設備描述符中記錄了管理一個磁盤塊需要的數(shù)據(jù)結(jié)構(gòu)或數(shù)據(jù)結(jié)構(gòu)的指針。我們設計的塊設備描述符，主要包括以下數(shù)據(jù)結(jié)構(gòu)：

1) 指向下層磁盤塊設備描述符的指針，對于文件系統(tǒng)來說，該指針通常指向下層磁盤緩存設備的描述符；

2) 塊設備的互斥訪問信號量，該信號量主要用來在掛載和卸載設備的時候?qū)υO備進行互斥訪問；

3) 打開文件的文件描述符數(shù)組和文件句柄數(shù)組，用來管理打開的文件；

4) 文件互斥訪問信號量數(shù)組；

5) 磁盤目錄區(qū)描述符，主要用來描述磁盤目錄區(qū)的使用情況；

6) 磁盤數(shù)據(jù)區(qū)描述符，主要用來描述磁盤數(shù)據(jù)區(qū)的使用情況；

7) 指向文件超級塊的指針，指向在掛載過程中讀入內(nèi)存的文件的超級塊結(jié)構(gòu)。

在接下來的幾小節(jié)，詳細描述上面涉及到的幾個數(shù)據(jù)結(jié)構(gòu)，以及對它們進行的優(yōu)化。

2.3 目錄區(qū)描述符

目錄區(qū)描述符主要用來管理磁盤塊設備上目錄區(qū)的分配。它主要包括3個指針，分別表示目錄區(qū)起始塊地址，目錄區(qū)終止塊地址，以及下一個空閑的目錄項編號（通過編號，可以快速計算出下一個文件項所在磁盤上的位置）。

由于在一個文件系統(tǒng)中不能有重名的文件，因此在創(chuàng)建新的文件時，必須確定新文件名不存在。如果每次在創(chuàng)建時，都需要將新文件名與已存在的文件名一一比較，這種線性的比較方式會隨著文件數(shù)量的增多而使新文件創(chuàng)建的所花費的時間越來越長。同樣，對于打開文件，刪除文件等操作，都需要我們能快速查找到文件。因此，要采用一種高效的方式在內(nèi)存中建立文件的索引。

采用動態(tài)哈希表來存放所有的已創(chuàng)建的文件，并在哈希表項中建立了文件名到文件元數(shù)據(jù)所在磁盤位置的映射。之所以說“動態(tài)”，是因該哈希表的某個桶中的元素數(shù)量超過一定值時，哈希表會動態(tài)擴張，從而使所有的桶中的元素數(shù)量處于一個門限之下。這樣，查找任何一個文件的時間，都不會隨著文件數(shù)量的增多而增長，且接近于常數(shù)時間。

2.4 數(shù)據(jù)區(qū)描述符

數(shù)據(jù)區(qū)描述符用來管理磁盤上的數(shù)據(jù)區(qū)域的分配，它主要包括3個指針。第一個指針（BEGIN）指向數(shù)據(jù)區(qū)起始塊，第二個指針（END）指向數(shù)據(jù)區(qū)終止塊，第三個指針（NEXT）指向下一個未被占用的磁盤塊。這樣，從BEGIN至NEXT-1的磁盤塊即為已用塊，而從NEXT至END的磁盤塊為空閑塊。

這種磁盤塊管理方式和文件系統(tǒng)采用的使用位圖來管理磁盤塊的方式有很大區(qū)別，主要有以下考慮：

1) 該文件系統(tǒng)主要的應用是針對機載記錄設備，而記錄文件通常不需要執(zhí)行文件的刪除操作。實際上，在IRIG 106的標準中，并不支持刪除（DELETE）命令，因此，文件系統(tǒng)并不用處理在刪除文件時面臨的磁盤空間回收問題。

2) 由于STANAG-4575標準規(guī)定了文件的數(shù)據(jù)必須連續(xù)存放，因此，系統(tǒng)采用在創(chuàng)建文件時一次性為文件分配空間的方法。若采用動態(tài)分配方式，則無法很好處理多個文件同時打開的情況。

由于VXWorks系統(tǒng)標準的創(chuàng)建文件（creat）的接口并不支持為文件預分配空間的操作。提供了一個新的函數(shù)creat64，可以上層應用程序通過輸入?yún)?shù)指定為函數(shù)預留的空間大小。

同時，還為應用程序提供了其他輔助函數(shù)，如getnfree64函數(shù)，它用來返回某個文件剩余可用空間的字節(jié)數(shù)。上層可以通過調(diào)用該函數(shù)確定什么時候需要關(guān)閉文件并創(chuàng)建新文件來記錄數(shù)據(jù)。

2.5 文件描述符和文件句柄

文件描述符數(shù)組用來管理文件系統(tǒng)中打開的文件。當一個進程打開一個文件時，文件系統(tǒng)就會為該進程分配一個文件描述符。

文件描述符中主要存放了打開文件的打開模式（讀/寫/讀寫），文件讀寫位置偏移等信息。各個進程都通過文件描述符來對文件進行讀寫訪問。

當多個進程同時打開一個文件時，它們可能同時對文件進行修改，因此需要將文件的重要元數(shù)據(jù)，如文件大小，只在內(nèi)存中存放一份，從而避免多個進程同時修改不同元數(shù)據(jù)造成的不一致。

通過文件句柄來存放這類文件元數(shù)據(jù)，當多個進程同時打開同一個文件時，系統(tǒng)會為每個進程創(chuàng)建一個文件描述符，而讓多個文件描述符共享同一個文件句柄。同時，為了保證互斥訪問，文件系統(tǒng)為該文件句柄提供了加鎖操作。即當某個進程需要對文件進行讀寫時，首先會對該文件句柄加鎖，再訪問，最后解鎖的操作，避免多個進程同時修改文件可能造成的混亂。

2.6 數(shù)據(jù)寫入順序控制

文件系統(tǒng)要解決斷電之后帶來的一致性的問題。之前，已經(jīng)通過只在文件系統(tǒng)超級塊中存放靜態(tài)數(shù)據(jù)，保證每次元數(shù)據(jù)的更新只會修改一個數(shù)據(jù)塊，解決了文件系統(tǒng)元數(shù)據(jù)可能的不一致問題。

對于文件系統(tǒng)數(shù)據(jù)的不一致問題，通過保證文件系統(tǒng)的元數(shù)據(jù)在文件系統(tǒng)數(shù)據(jù)之后，寫入磁盤的方式來解決。具體做法是，對于一次文件的寫入操作，首先將數(shù)據(jù)寫入文件系統(tǒng)的磁盤緩存之中，之后，再更元數(shù)據(jù)。當要將元數(shù)據(jù)寫入緩存之前，首先，將該文件對應的所有數(shù)據(jù)都寫入磁盤。這樣，既可保證文件系統(tǒng)的數(shù)據(jù)在磁盤上是永遠一致的。

當然，這里面還有很多優(yōu)化的問題。比如，應該將數(shù)據(jù)積累到一定量再做一次寫磁盤的操作，或者一定的時間進行一次寫磁盤的操作，從而保證系統(tǒng)的記錄性能。

3 系統(tǒng)測試

將自己實現(xiàn)的STANAG-4575文件系統(tǒng)和VXWorks本地的dosFs文件系統(tǒng)進行了一系列測試，來對比它們之間的性能，測試環(huán)境，如表1所示：

表1 測試環(huán)境

3.1 單線程寫單文件測試

記錄文件系統(tǒng)最常用的方式即為單線程寫單文件測試。測試讓一個線程以不同的塊大小來寫一個4G大文件，測試結(jié)果，如圖4所示：

圖4 單線程寫文件性能測試

從測試中可以看出，實現(xiàn)的STANAG-4575文件系統(tǒng)的寫入性能要高于VXWorks本地的dosFs文件系統(tǒng)。主要原因主要有：

1) STANAG-4575中文件數(shù)據(jù)連續(xù)存放，可以提供更快的寫入性能；

2) dosFs在寫操作時可能伴隨著文件空間的分配等操作，而這些操作會影響文件的寫入性能。而STANAG-4575文件數(shù)據(jù)塊一次分配，減少了之后動態(tài)分配帶來的性能下降。

3.2 多線程寫文件測試

在真實的環(huán)境中，記錄設備會采用多個線程，用來記錄從不同的通道傳來的數(shù)據(jù)，因此，需要對多線程寫文件的性能進行測試。測試采用10個線程，每個線程寫入4G的文件。測試結(jié)果，如圖5所示：

圖5 多線程寫文件性能測試

從測試中可以看出，實現(xiàn)的 STANAG-4575文件系統(tǒng)在多線程寫文件的情況下，性能也是要高于VXWorks本地文件系統(tǒng)的。該情況，原因與單線程寫文件時的情況類似，只是由于線程切換的開銷，導致兩種情況下文件系統(tǒng)的性能都要低于單線程寫文件的性能。

4 總結(jié)

本文主要介紹了一種 IRIG 106下層文件系統(tǒng)STANAG-4575的實現(xiàn)方法。通過以下途徑實現(xiàn)：

1） 對文件系統(tǒng)的元數(shù)據(jù)進行校驗和備份的方式實現(xiàn)文件系統(tǒng)的可靠性；

2） 通過在內(nèi)存中建立哈希表等方式實現(xiàn)文件系統(tǒng)的高性能；

3） 通過對標準定義的磁盤結(jié)構(gòu)的靈活變通，進一步優(yōu)化了文件系統(tǒng)的寫入性能。

4） 通過控制元數(shù)據(jù)和數(shù)據(jù)的寫入方式來保證數(shù)據(jù)在磁盤上的一致性。

在下一步的工作中，可能會重新設計并實現(xiàn) VXWorks文件系統(tǒng)下層的磁盤緩存，以使它可以更加符合應用的需求。我們還會參考其他文件系統(tǒng)的做法，采用日志的方式來進一步提高文件系統(tǒng)的可靠性。

[1]Jeff Bonwick, Matt Ahrens, Val Henson, Mark Maybee,Mark Shellenbaum, [M]”The Zettabyte File System”.2002.

[2]Marshall Kirk McKusick, William N.Joy, Samuel J.Leffler, Robert S.Fabry, ” [M]A Fast File System for Unix”.

[3]T.J.Kowalski and Marshall K. McKusick. Fsck-the UNIX file system check program.Technical report, [C]Bell Laboratories, March 1978.

[4]Lihua Yu, Gang Chen, Wei Wang, Jinxiang Dong.MSFSS: A Storage System for Mass Small Files. in Proceedings of the 11th International Conference [C]on Computer Supported Cooperative Work in Design,2007.

[5]Larry W.McVoy and Steve R.Kleiman. Extent-like performance from a UNIX file system. [C]In Proceedings of the 1991 USENIX Winter Technical Conference,1991

[6]R.J.T.Morris, B.J.Truskowski.The evolution of storage. [J]IBM SYSTEMS JOURNAL,VOL42, NO2, 2003.

[7]MENDEL ROSENBLUM,JOHN K. OUSTERHOUTLFS.The Designand Implementation of a Log-Structured File System. [J]ACM Transactions on Computer Systems,Vol 10, No. 1, February 1992, Pages 26-52.

[8]Vilayannur,M. Kandemir,M; Sivasubramaniam, A Kernel-level caching for optimizing I/O by exploiting inter-applicationdata sharing. [M]Cluster Computeing,2002.

[9][C]VXWorks Programmer’s Guide 5.5

[10][C]Dominic Giampaolo “Practical File System Design with the Be File System”