ROMFS - ROM檔案系統

這是一種相當簡單、只讀的檔案系統，主要用於安裝盤的初始RAM磁碟。它的出現是為了滿足在啟動時連結模組的需求。使用這種檔案系統，你可以獲得一個非常相似的功能，甚至是一個小核心的可能性，而且其檔案系統不會佔用你辦公室地下室路由器功能所需的有用記憶體。

相比之下，較舊的minix和xiafs（後者現已廢棄）檔案系統，編譯為模組時需要超過20000位元組，而romfs不足一個頁面，大約4000位元組（假設i586程式碼）。在相同條件下，msdos檔案系統大約需要30K（並且不支援裝置節點或符號連結），而帶有nfsroot的nfs模組大約需要57K。此外，作為一個稍顯不公平的比較，一個實際的救援盤使用ext2時佔用了3202個塊，而使用romfs時，它只需要3079個塊。

要建立這樣一個檔案系統，你需要一個名為genromfs的使用者程式。它可以在 http://romfs.sourceforge.net/ 獲取。

顧名思義，如果有人有動力，romfs也可以（節省空間地）用於各種只讀介質，例如(E)EPROM磁碟.. :)

然而，romfs的主要目的是擁有一個非常小的核心，其中只連結了此檔案系統，然後可以使用當前的模組工具在以後載入任何模組。它還可以用於執行某些程式來決定是否需要SCSI裝置，甚至IDE或軟盤驅動器也可以在以後載入，如果你使用核心的“initrd”（初始RAM磁碟）特性。這算不上什麼新聞，但有了romfs，你甚至可以暫時不載入你的ext2、minix或甚至affs檔案系統，直到你真正知道需要它們為止。

例如，一個發行版啟動盤可以只包含CD驅動器（可能還有SCSI驅動器）和ISO 9660檔案系統模組。核心可以足夠小，因為它不包含其他檔案系統，例如相當大的ext2fs模組，後者可以在安裝的後期從CD載入。另一個用途是作為恢復盤，當您從網路重新安裝工作站時，所有工具/模組都可從附近的伺服器獲得，因此您不想為此目的攜帶兩張磁碟，僅僅因為它們無法放入ext2。

romfs如你所料在塊裝置上執行，其底層結構非常簡單。每個可訪問的結構都從16位元組邊界開始，以實現快速訪問。檔案佔用的最小空間是32位元組（這是一個空檔案，檔名少於16個字元）。任何非空檔案的最大開銷是檔案頭，以及名稱和內容各自的16位元組填充，總計16+14+15 = 45位元組。然而，這種情況相當罕見，因為大多數檔名都長於3位元組且短於15位元組。

檔案系統的佈局如下：

offset     content

       +---+---+---+---+
 0     | - | r | o | m |  \
       +---+---+---+---+       The ASCII representation of those bytes
 4     | 1 | f | s | - |  /    (i.e. "-rom1fs-")
       +---+---+---+---+
 8     |   full size   |       The number of accessible bytes in this fs.
       +---+---+---+---+
12     |    checksum   |       The checksum of the FIRST 512 BYTES.
       +---+---+---+---+
16     | volume name   |       The zero terminated name of the volume,
       :               :       padded to 16 byte boundary.
       +---+---+---+---+
xx     |     file      |
       :    headers    :

每個多位元組值（32位字，從現在起我將使用“長字”這個術語）都必須採用大端位元組序。

前八個位元組用於識別檔案系統，即使是隨意檢視者也能識別。之後，在第三個長字中，它包含從檔案系統開始可訪問的位元組數。第四個長字是前512位元組（或可訪問的位元組數，取兩者中較小者）的校驗和。所採用的演算法與AFFS檔案系統中的相同，即長字（再次假定為大端量）的簡單和。有關詳細資訊，請查閱原始碼。選擇此演算法是因為儘管它不太可靠，但它不需要任何表格，並且非常簡單。

以下位元組現在是檔案系統的一部分；每個檔案頭必須在16位元組邊界上開始。

offset     content

       +---+---+---+---+
 0     | next filehdr|X|       The offset of the next file header
       +---+---+---+---+         (zero if no more files)
 4     |   spec.info   |       Info for directories/hard links/devices
       +---+---+---+---+
 8     |     size      |       The size of this file in bytes
       +---+---+---+---+
12     |   checksum    |       Covering the meta data, including the file
       +---+---+---+---+         name, and padding
16     | file name     |       The zero terminated name of the file,
       :               :       padded to 16 byte boundary
       +---+---+---+---+
xx     | file data     |
       :               :

由於檔案頭始終從16位元組邊界開始，因此在下一個filehdr指標中，最低4位將始終為零。這四位用於模式資訊。位0..2指定檔案型別；位4則指示檔案是否可執行。如果未設定該位，則許可權被假定為全域性可讀；如果設定了，則假定為全域性可執行；字元裝置和塊裝置除外，它們除所有者外永遠不可訪問。每個檔案的所有者是使用者和組0，這對於預期用途來說不應該成為問題。8個可能值到檔案型別的對映如下：

0

硬連結

連結目標 [檔案頭]

1

目錄

第一個檔案的檔案頭

2

普通檔案

未使用，必須為零 [MBZ]

3

符號連結

未使用，MBZ (檔案資料為連結內容)

4

塊裝置

16/16 位主/次裝置號

5

字元裝置

  • “ -

6

套接字

未使用，MBZ

7

FIFO (命名管道)

未使用，MBZ

請注意，硬連結在此檔案系統中被特別標記，但它們的行為與你所期望的一致（即共享inode號）。另請注意，你有責任不建立硬連結迴圈，併為目錄建立所有“.”和“..”連結。這通常由genromfs程式正確完成。請避免在套接字和FIFO特殊檔案上將可執行位用於特殊目的，它們將來可能另有他用。此外，請記住，只有普通檔案和符號連結才應具有非零大小欄位；它們包含（填充後的）檔名之後直接可用的位元組數。

另一點需要注意的是，romfs在檔案頭和資料上都按16位元組邊界對齊，但大多數硬體裝置和塊裝置驅動程式無法處理小於塊大小的資料。為了克服此限制，檔案系統的總大小必須填充到1024位元組邊界。

如果您對此檔案系統有任何問題或建議，請聯絡我。但是，在要求我新增功能和程式碼之前請三思，因為此檔案系統的主要和最重要優點是程式碼量小。另一方面，請不要擔心，我沒有收到那麼多與romfs相關的郵件。現在我能理解為什麼Avery在ARCnet文件中寫詩是為了獲得更多反饋了。 :)

romfs也有一個郵件列表，迄今為止，它還沒有收到任何流量，因此歡迎您加入以討論您的想法。 :)

它由ezmlm執行，因此您可以透過向 romfs-subscribe@shadow.banki.hu 傳送郵件來訂閱，郵件內容無關緊要。

待解決問題

  • 許可權和所有者資訊是類Unix系統的重要特性，但romfs沒有提供全部可能性。我從未覺得這有限制，但其他人可能會。

  • 該檔案系統是隻讀的，因此可以非常小，但如果有人想對檔案系統寫入_任何東西_，他仍然需要一個可寫的檔案系統，從而抵消了大小優勢。可能的解決方案：將寫訪問實現為編譯時選項，或者為RAM磁碟提供一個新的、同樣小的可寫檔案系統。

  • 由於檔案只要求在16位元組邊界上對齊，目前從檔案系統讀取或執行檔案可能不是最優的。這可以透過重新排序檔案資料來解決，使其大部分（即除了開頭和結尾）位於“自然”邊界上，從而可以將檔案內容的很大一部分直接對映到mm子系統。

  • 壓縮可能是一個有用的功能，但在我看來，記憶體是一個相當大的限制因素。

  • 它在哪裡使用？

  • 它是否在Intel和Motorola之外的其他架構上工作？

祝好，

Janos Farkas <chexum@shadow.banki.hu>