romfs - rom文件系统

ROMFS - ROM文件系统 *************************************************** 我把genromfs-0.5.2 --Janos Farkas的文档原文 用google翻译后进行修改。 http://romfs.sourceforge.net ljhhh0123 2009-10-2 注: 本人由于对英语不太懂,只能以理解到的计算机知识,和用金山词霸 的即时翻译,来把google自动翻译的文章变得通顺一点. 网上有人说“ROMFS用于文件寻址的字段实际上只有28bit，”， 而事实上，由于文件对齐到16字节边界，文件寻址时低四位必须清0， 并不是说就不参与寻址了，实际上寻址地址还是32位， 而原来的这低四位存的就是文件的模式信息。 *************************************************** ROMFS - ROM文件系统 这是一个相当无能的，只读的文件系统. 主要用于初始化 安装盘上的RAM disks。它产生于需要模块链接的系统启动过程中。 使用这个文件系统，您会获得一个非常 类似的功能，甚至这可能是一个很小的内核,而这个 文件系统并不占用很多您墙角的路由器有用的内存。 为了比较，两个较老的minix和xiafs（后者现 已死掉）文件系统，编译一个模块需要超过20000字节的汇编， 而romfs小于1页，大概是4000个字节（假设i586 代码）。在相同条件下，msdos文件系统将需要 约30K（不支持的设备节点或符号）字节，而 NFS模块与nfsroot的约57K。此外，有点不公平 相比之下，一个实际的急救盘用了3202块的ext2文件系统，而 与romfs，它需要3079块。 要创建这样一个文件系统，您需要一个叫genromfs的用户程序。 它可通过匿名ftp上sunsite.unc.edu和 它的镜像在/pub/Linux/system/recovery/ 目录。 顾名思义，romfs也可以使用（空间效率）在 各种只读媒体,像(E)EPROM，如果有人有这个动机的话 .. ： 然而，romfs的主要目的是有一个非常小的内核， 使用当前的模块工具,也只有这种链接的文件系统才可以延迟加载任何模块. 它也可以用来运行一些程序来决定是否需要SCSI设备，甚至是IDE或 软盘驱动器可以加载以后，如果您使用“initrd” -初始 RAM disks--内核的功能。这不会是真正的闪光点， 但,使用romfs，你甚至可以把您的ext2或minix文件系统作为备用， 直到你真的需要它时再开启。 例如，一个发行版的启动盘只包含CD光盘 驱动器（也可能是SCSI驱动器），和ISO 9660文件系统 模块。该内核可以足够小，因为它没有其他 文件系统，就像相当大的ext2fs模块，然后可以 在安装的后期关闭CD。另一种用法 是恢复磁盘,当您从网络重新安装工作站， 从附近的服务器上，你将拥有所有的工具/模块, 因此你不想携带两个磁盘， 只是因为它不适合用在ext2文件系统。 你可以预期romfs块设备的运作，以及非常简单的底层 结构。每一个可理解的结构都以16字节为边界对齐,因而可以快速访问. 最低空间的文件会是32个字节（这是一个空文件,只有一个文件头）。 对于任何开销最大的非空的文件是16字节填充的文件头和内容，就是16 +14 +15 = 45 字节。这不过是相当罕见，因为大多数的文件名长度 超过3个字节，而短于15字节。 (译者注:我的理解是最小的文件只是一个文件头,32字节;开销最大的的文件是 16(文件头:头16个字节)+14(文件名:一个字符加一个/0之后填充的14个字节) +15(文件内容:一个字节文件内容,却要填充15个字节来对齐到16字节) 文件系统的布局如下： offset content +---+---+---+---+ 0 | - | r | o | m | / +---+---+---+---+ 这些字节的ASCII表示 4 | 1 | f | s | - | / (如： "-rom1fs-") +---+---+---+---+ 8 | full size | 本文件系统的总大小（以字节算）. +---+---+---+---+ 12 | checksum | 头512字节的校验值. +---+---+---+---+ 16 | volume name | 以0结尾的卷标名，并填充到16字节的边界处（最大16字节）。 : : +---+---+---+---+ xx | file | : headers : 文件头。 每一个多字节值（32位的话，我从现在开始就叫它longwords）必须用big-endian存放。 前8个字节是文件系统id，用来检查文件系统。 之后的4个字节内容是本文系统的大小（以字节算）。 再之后的四个字节是本文件的前512字节的校验值(checksum)（或本文件可访问的 字节数，以较少者为准(这在文件小于512字节时用到)）。 这里应用的算法是和AFFS filesystem是相同的， 即longwords的简单相加(用连续的big-endian数相加)。 有关详情，请咨询相关源。该算法被选中的原因，虽然它不是很 可靠的，但它不需要任何表，这是非常简单的。 （注：此算法就把文件分成big-endian连续的32位数，然后相加） 以下字节现在是文件系统的一部分，每一个文件头 必须开始一个16字节的边界。 offset content +---+---+---+---+ 0 | next filehdr|X| 下一个文件头的偏移|模式信息 +---+---+---+---+ (如果没有更多的文件就是0) 4 | spec.info | directories/hard/links/devices的信息 +---+---+---+---+ 8 | size | 文件的大小（以字节算） +---+---+---+---+ 12 | checksum | 包含元数据，文件名，和填充的内容 +---+---+---+---+ 16 | file name | 以0结尾的文件名，并填充到16字节的边界处（最大16字节）。 : : +---+---+---+---+ xx | file data | 文件的数据内容。 : : 由于文件头开始于16字节的边界处，最低 4位将永远是零，在未来filehdr指针。这四个 位用于模式的信息。位0..2位指定文件类型; 而第3位显示该文件是否是可执行文件。那个 权限被假定为世界可读，如果此位未设置， 而它又是世界执行的;除了字符和块设备， 它们从来没有被其他人使用过。每个 文件的拥有者都是user和group 0，这不应该成为问题 。这8种可能的值的对应的文件类型如下： mapping spec.info means 0 hard link(硬链接) 链接目标[文件头] 1 directory (目录) 第一个文件头 2 regular file(普通文件) 未使用的，必须是零(MBZ) 3 symbolic link(符号链接) 未使用，必须为0. 4 block device(块设备) 16/16位 主要/次要号码 5 char device(字符设备) 16/16位 主要/次要号码 6 socket(套接口) 未使用的，必须为0. 7 fifo (管道) 未使用的，必须为0. 请注意，硬链接是这个文件系统的特点，但 你要预料它们的表现行为（例如：共享inode号）。 还要注意，您的责任是不能创建硬链接 循环，并创建所有的.和..目录的链接。而这是 通常是正确的genromfs程序。请不要 为socket和FIFO的特殊用途而使用的可执行位， 他们可能在未来有其他用途。此外， 请记住，普通文件和符号链接都应该 有一个非零大小字段，它们包含可用的字节数 和经填充后的文件名称。 另一件需要注意的是romfs的文件头和数据工程 对齐到16字节边界，但大多数硬件设备和块 设备驱动程序无法应付多块的小规模的数据。 为了克服这种局限性，该文件系统的整体大小必须 填充到一个1024字节的边界。 如果您对这个文件系统有任何问题或建议， 请与我联系。然而，三思而后要我补充 特性和代码，因为首要的和最重要的优势 这个文件系统是小的代码。另一方面，不要 震惊，我没能获得这么多romfs相关邮件。现在我可以 明白Avery为什么在ARCnet的文档写诗以争取多一些 反馈。 ：） romfs也有一个邮件列表，到目前为止，还没有收到任何 流量，因此欢迎您加入，并讨论您的想法。 ：） 它的运行ezmlm，所以你可以订阅，发送消息 到romfs-subscribe@shadow.banki.hu，内容是无关紧要的。 这是一个关于romfs的网页： http://romfs.sourceforge.net 有待解决的问题： - 在UN*X系统，权限和所有者的信息是非常重要的一个特征， 但romfs没有提供充分的可能性。 我从来没有发现这个限制，但其他人可能。 - 文件系统是只读的，因此它可以非常小，但万一 人会想要写_anything_到一个文件系统，他还需要 可写的文件系统，从而否定了规模优势。可能 解决方案：实现一个可写的编译时选项;或一个全新的， 同样小的可写文件系统RAM磁盘。 - 由于文件只要求有一个16字节对齐 边界，它目前可能不理想读取或执行文件 从文件系统。也许是解决文件数据重新排序 有大部分（除了开始和结束，即）铺设在“自然” 疆界，从而将有可能直接映射大一部分 文件内容到毫米子系统。 - 压缩可能是一个有用的功能，但在我眼里，内存是一个相当 限制的因素。 - 在哪里可以用到它？ - 能否在英特尔和摩托罗拉以外的架构下工作？ 玩得开心， Janos Farkas <chexum@shadow.banki.hu> ********************************************** 英文原文： ********************************************** ROMFS - ROM FILE SYSTEM This is a quite dumb, read only filesystem, mainly for initial RAM disks of installation disks. It has grown up by the need of having modules linked at boot time. Using this filesystem, you get a very similar feature, and even the possibility of a small kernel, with a file system which doesn't take up useful memory from the router functions in the basement of your office. For comparison, both the older minix and xiafs (the latter is now defunct) filesystems, compiled as module need more than 20000 bytes, while romfs is less than a page, about 4000 bytes (assuming i586 code). Under the same conditions, the msdos filesystem would need about 30K (and does not support device nodes or symlinks), while the nfs module with nfsroot is about 57K. Furthermore, as a bit unfair comparison, an actual rescue disk used up 3202 blocks with ext2, while with romfs, it needed 3079 blocks. To create such a file system, you'll need a user program named genromfs. It is available via anonymous ftp on sunsite.unc.edu and its mirrors, in the /pub/Linux/system/recovery/ directory. As the name suggests, romfs could be also used (space-efficiently) on various read-only media, like (E)EPROM disks if someone will have the motivation.. :) However, the main purpose of romfs is to have a very small kernel, which has only this filesystem linked in, and then can load any module later, with the current module utilities. It can also be used to run some program to decide if you need SCSI devices, and even IDE or floppy drives can be loaded later if you use the "initrd"--initial RAM disk--feature of the kernel. This would not be really news flash, but with romfs, you can even spare off your ext2 or minix or maybe even affs filesystem until you really know that you need it. For example, a distribution boot disk can contain only the cd disk drivers (and possibly the SCSI drivers), and the ISO 9660 filesystem module. The kernel can be small enough, since it doesn't have other filesystems, like the quite large ext2fs module, which can then be loaded off the CD at a later stage of the installation. Another use would be for a recovery disk, when you are reinstalling a workstation from the network, and you will have all the tools/modules available from a nearby server, so you don't want to carry two disks for this purpose, just because it won't fit into ext2. romfs operates on block devices as you can expect, and the underlying structure is very simple. Every accessible structure begins on 16 byte boundaries for fast access. The minimum space a file will take is 32 bytes (this is an empty file, with a less than 16 character name). The maximum overhead for any non-empty file is the header, and the 16 byte padding for the name and the contents, also 16+14+15 = 45 bytes. This is quite rare however, since most file names are longer than 3 bytes, and shorter than 15 bytes. The layout of the filesystem is the following: 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 : Every multi byte value (32 bit words, I'll use the longwords term from now on) must be in big endian order. The first eight bytes identify the filesystem, even for the casual inspector. After that, in the 3rd longword, it contains the number of bytes accessible from the start of this filesystem. The 4th longword is the checksum of the first 512 bytes (or the number of bytes accessible, whichever is smaller). The applied algorithm is the same as in the AFFS filesystem, namely a simple sum of the longwords (assuming bigendian quantities again). For details, please consult the source. This algorithm was chosen because although it's not quite reliable, it does not require any tables, and it is very simple. The following bytes are now part of the file system; each file header must begin on a 16 byte boundary. 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 | : : Since the file headers begin always at a 16 byte boundary, the lowest 4 bits would be always zero in the next filehdr pointer. These four bits are used for the mode information. Bits 0..2 specify the type of the file; while bit 3 shows if the file is executable or not. The permissions are assumed to be world readable, if this bit is not set, and world executable if it is; except the character and block devices, they are never accessible for other than owner. The owner of every file is user and group 0, this should never be a problem for the intended use. The mapping of the 8 possible values to file types is the following: mapping spec.info means 0 hard link link destination [file header] 1 directory first file's header 2 regular file unused, must be zero [MBZ] 3 symbolic link unused, MBZ (file data is the link content) 4 block device 16/16 bits major/minor number 5 char device - " - 6 socket unused, MBZ 7 fifo unused, MBZ Note that hard links are specifically marked in this filesystem, but they will behave as you can expect (i.e. share the inode number). Note also that it is your responsibility to not create hard link loops, and creating all the . and .. links for directories. This is normally done correctly by the genromfs program. Please refrain from using the executable bits for special purposes on the socket and fifo special files, they may have other uses in the future. Additionally, please remember that only regular files, and symlinks are supposed to have a nonzero size field; they contain the number of bytes available directly after the (padded) file name. Another thing to note is that romfs works on file headers and data aligned to 16 byte boundaries, but most hardware devices and the block device drivers are unable to cope with smaller than block-sized data. To overcome this limitation, the whole size of the file system must be padded to an 1024 byte boundary. If you have any problems or suggestions concerning this file system, please contact me. However, think twice before wanting me to add features and code, because the primary and most important advantage of this file system is the small code. On the other hand, don't be alarmed, I'm not getting that much romfs related mail. Now I can understand why Avery wrote poems in the ARCnet docs to get some more feedback. :) romfs has also a mailing list, and to date, it hasn't received any traffic, so you are welcome to join it to discuss your ideas. :) It's run by ezmlm, so you can subscribe to it by sending a message to romfs-subscribe@shadow.banki.hu, the content is irrelevant. There is a web page about romfs at: http://romfs.sourceforge.net Pending issues: - Permissions and owner information are pretty essential features of a Un*x like system, but romfs does not provide the full possibilities. I have never found this limiting, but others might. - The file system is read only, so it can be very small, but in case one would want to write _anything_ to a file system, he still needs a writable file system, thus negating the size advantages. Possible solutions: implement write access as a compile-time option, or a new, similarly small writable filesystem for RAM disks. - Since the files are only required to have alignment on a 16 byte boundary, it is currently possibly suboptimal to read or execute files from the filesystem. It might be resolved by reordering file data to have most of it (i.e. except the start and the end) laying at "natural" boundaries, thus it would be possible to directly map a big portion of the file contents to the mm subsystem. - Compression might be an useful feature, but memory is quite a limiting factor in my eyes. - Where it is used? - Does it work on other architectures than intel and motorola? Have fun, Janos Farkas <chexum@shadow.banki.hu>