0001 .. SPDX-License-Identifier: GPL-2.0
0002
0003 =======================
0004 ROMFS - ROM File System
0005 =======================
0006
0007 This is a quite dumb, read only filesystem, mainly for initial RAM
0008 disks of installation disks. It has grown up by the need of having
0009 modules linked at boot time. Using this filesystem, you get a very
0010 similar feature, and even the possibility of a small kernel, with a
0011 file system which doesn't take up useful memory from the router
0012 functions in the basement of your office.
0013
0014 For comparison, both the older minix and xiafs (the latter is now
0015 defunct) filesystems, compiled as module need more than 20000 bytes,
0016 while romfs is less than a page, about 4000 bytes (assuming i586
0017 code). Under the same conditions, the msdos filesystem would need
0018 about 30K (and does not support device nodes or symlinks), while the
0019 nfs module with nfsroot is about 57K. Furthermore, as a bit unfair
0020 comparison, an actual rescue disk used up 3202 blocks with ext2, while
0021 with romfs, it needed 3079 blocks.
0022
0023 To create such a file system, you'll need a user program named
0024 genromfs. It is available on http://romfs.sourceforge.net/
0025
0026 As the name suggests, romfs could be also used (space-efficiently) on
0027 various read-only media, like (E)EPROM disks if someone will have the
0028 motivation.. :)
0029
0030 However, the main purpose of romfs is to have a very small kernel,
0031 which has only this filesystem linked in, and then can load any module
0032 later, with the current module utilities. It can also be used to run
0033 some program to decide if you need SCSI devices, and even IDE or
0034 floppy drives can be loaded later if you use the "initrd"--initial
0035 RAM disk--feature of the kernel. This would not be really news
0036 flash, but with romfs, you can even spare off your ext2 or minix or
0037 maybe even affs filesystem until you really know that you need it.
0038
0039 For example, a distribution boot disk can contain only the cd disk
0040 drivers (and possibly the SCSI drivers), and the ISO 9660 filesystem
0041 module. The kernel can be small enough, since it doesn't have other
0042 filesystems, like the quite large ext2fs module, which can then be
0043 loaded off the CD at a later stage of the installation. Another use
0044 would be for a recovery disk, when you are reinstalling a workstation
0045 from the network, and you will have all the tools/modules available
0046 from a nearby server, so you don't want to carry two disks for this
0047 purpose, just because it won't fit into ext2.
0048
0049 romfs operates on block devices as you can expect, and the underlying
0050 structure is very simple. Every accessible structure begins on 16
0051 byte boundaries for fast access. The minimum space a file will take
0052 is 32 bytes (this is an empty file, with a less than 16 character
0053 name). The maximum overhead for any non-empty file is the header, and
0054 the 16 byte padding for the name and the contents, also 16+14+15 = 45
0055 bytes. This is quite rare however, since most file names are longer
0056 than 3 bytes, and shorter than 15 bytes.
0057
0058 The layout of the filesystem is the following::
0059
0060 offset content
0061
0062 +---+---+---+---+
0063 0 | - | r | o | m | \
0064 +---+---+---+---+ The ASCII representation of those bytes
0065 4 | 1 | f | s | - | / (i.e. "-rom1fs-")
0066 +---+---+---+---+
0067 8 | full size | The number of accessible bytes in this fs.
0068 +---+---+---+---+
0069 12 | checksum | The checksum of the FIRST 512 BYTES.
0070 +---+---+---+---+
0071 16 | volume name | The zero terminated name of the volume,
0072 : : padded to 16 byte boundary.
0073 +---+---+---+---+
0074 xx | file |
0075 : headers :
0076
0077 Every multi byte value (32 bit words, I'll use the longwords term from
0078 now on) must be in big endian order.
0079
0080 The first eight bytes identify the filesystem, even for the casual
0081 inspector. After that, in the 3rd longword, it contains the number of
0082 bytes accessible from the start of this filesystem. The 4th longword
0083 is the checksum of the first 512 bytes (or the number of bytes
0084 accessible, whichever is smaller). The applied algorithm is the same
0085 as in the AFFS filesystem, namely a simple sum of the longwords
0086 (assuming bigendian quantities again). For details, please consult
0087 the source. This algorithm was chosen because although it's not quite
0088 reliable, it does not require any tables, and it is very simple.
0089
0090 The following bytes are now part of the file system; each file header
0091 must begin on a 16 byte boundary::
0092
0093 offset content
0094
0095 +---+---+---+---+
0096 0 | next filehdr|X| The offset of the next file header
0097 +---+---+---+---+ (zero if no more files)
0098 4 | spec.info | Info for directories/hard links/devices
0099 +---+---+---+---+
0100 8 | size | The size of this file in bytes
0101 +---+---+---+---+
0102 12 | checksum | Covering the meta data, including the file
0103 +---+---+---+---+ name, and padding
0104 16 | file name | The zero terminated name of the file,
0105 : : padded to 16 byte boundary
0106 +---+---+---+---+
0107 xx | file data |
0108 : :
0109
0110 Since the file headers begin always at a 16 byte boundary, the lowest
0111 4 bits would be always zero in the next filehdr pointer. These four
0112 bits are used for the mode information. Bits 0..2 specify the type of
0113 the file; while bit 4 shows if the file is executable or not. The
0114 permissions are assumed to be world readable, if this bit is not set,
0115 and world executable if it is; except the character and block devices,
0116 they are never accessible for other than owner. The owner of every
0117 file is user and group 0, this should never be a problem for the
0118 intended use. The mapping of the 8 possible values to file types is
0119 the following:
0120
0121 == =============== ============================================
0122 mapping spec.info means
0123 == =============== ============================================
0124 0 hard link link destination [file header]
0125 1 directory first file's header
0126 2 regular file unused, must be zero [MBZ]
0127 3 symbolic link unused, MBZ (file data is the link content)
0128 4 block device 16/16 bits major/minor number
0129 5 char device - " -
0130 6 socket unused, MBZ
0131 7 fifo unused, MBZ
0132 == =============== ============================================
0133
0134 Note that hard links are specifically marked in this filesystem, but
0135 they will behave as you can expect (i.e. share the inode number).
0136 Note also that it is your responsibility to not create hard link
0137 loops, and creating all the . and .. links for directories. This is
0138 normally done correctly by the genromfs program. Please refrain from
0139 using the executable bits for special purposes on the socket and fifo
0140 special files, they may have other uses in the future. Additionally,
0141 please remember that only regular files, and symlinks are supposed to
0142 have a nonzero size field; they contain the number of bytes available
0143 directly after the (padded) file name.
0144
0145 Another thing to note is that romfs works on file headers and data
0146 aligned to 16 byte boundaries, but most hardware devices and the block
0147 device drivers are unable to cope with smaller than block-sized data.
0148 To overcome this limitation, the whole size of the file system must be
0149 padded to an 1024 byte boundary.
0150
0151 If you have any problems or suggestions concerning this file system,
0152 please contact me. However, think twice before wanting me to add
0153 features and code, because the primary and most important advantage of
0154 this file system is the small code. On the other hand, don't be
0155 alarmed, I'm not getting that much romfs related mail. Now I can
0156 understand why Avery wrote poems in the ARCnet docs to get some more
0157 feedback. :)
0158
0159 romfs has also a mailing list, and to date, it hasn't received any
0160 traffic, so you are welcome to join it to discuss your ideas. :)
0161
0162 It's run by ezmlm, so you can subscribe to it by sending a message
0163 to romfs-subscribe@shadow.banki.hu, the content is irrelevant.
0164
0165 Pending issues:
0166
0167 - Permissions and owner information are pretty essential features of a
0168 Un*x like system, but romfs does not provide the full possibilities.
0169 I have never found this limiting, but others might.
0170
0171 - The file system is read only, so it can be very small, but in case
0172 one would want to write _anything_ to a file system, he still needs
0173 a writable file system, thus negating the size advantages. Possible
0174 solutions: implement write access as a compile-time option, or a new,
0175 similarly small writable filesystem for RAM disks.
0176
0177 - Since the files are only required to have alignment on a 16 byte
0178 boundary, it is currently possibly suboptimal to read or execute files
0179 from the filesystem. It might be resolved by reordering file data to
0180 have most of it (i.e. except the start and the end) laying at "natural"
0181 boundaries, thus it would be possible to directly map a big portion of
0182 the file contents to the mm subsystem.
0183
0184 - Compression might be an useful feature, but memory is quite a
0185 limiting factor in my eyes.
0186
0187 - Where it is used?
0188
0189 - Does it work on other architectures than intel and motorola?
0190
0191
0192 Have fun,
0193
0194 Janos Farkas <chexum@shadow.banki.hu>
