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>