Based on kernel version 2.6.26. Page generated on 2008-07-16 21:12 EST.
1 ROMFS - ROM FILE SYSTEM 2 3 This is a quite dumb, read only filesystem, mainly for initial RAM 4 disks of installation disks. It has grown up by the need of having 5 modules linked at boot time. Using this filesystem, you get a very 6 similar feature, and even the possibility of a small kernel, with a 7 file system which doesn't take up useful memory from the router 8 functions in the basement of your office. 9 10 For comparison, both the older minix and xiafs (the latter is now 11 defunct) filesystems, compiled as module need more than 20000 bytes, 12 while romfs is less than a page, about 4000 bytes (assuming i586 13 code). Under the same conditions, the msdos filesystem would need 14 about 30K (and does not support device nodes or symlinks), while the 15 nfs module with nfsroot is about 57K. Furthermore, as a bit unfair 16 comparison, an actual rescue disk used up 3202 blocks with ext2, while 17 with romfs, it needed 3079 blocks. 18 19 To create such a file system, you'll need a user program named 20 genromfs. It is available via anonymous ftp on sunsite.unc.edu and 21 its mirrors, in the /pub/Linux/system/recovery/ directory. 22 23 As the name suggests, romfs could be also used (space-efficiently) on 24 various read-only media, like (E)EPROM disks if someone will have the 25 motivation.. :) 26 27 However, the main purpose of romfs is to have a very small kernel, 28 which has only this filesystem linked in, and then can load any module 29 later, with the current module utilities. It can also be used to run 30 some program to decide if you need SCSI devices, and even IDE or 31 floppy drives can be loaded later if you use the "initrd"--initial 32 RAM disk--feature of the kernel. This would not be really news 33 flash, but with romfs, you can even spare off your ext2 or minix or 34 maybe even affs filesystem until you really know that you need it. 35 36 For example, a distribution boot disk can contain only the cd disk 37 drivers (and possibly the SCSI drivers), and the ISO 9660 filesystem 38 module. The kernel can be small enough, since it doesn't have other 39 filesystems, like the quite large ext2fs module, which can then be 40 loaded off the CD at a later stage of the installation. Another use 41 would be for a recovery disk, when you are reinstalling a workstation 42 from the network, and you will have all the tools/modules available 43 from a nearby server, so you don't want to carry two disks for this 44 purpose, just because it won't fit into ext2. 45 46 romfs operates on block devices as you can expect, and the underlying 47 structure is very simple. Every accessible structure begins on 16 48 byte boundaries for fast access. The minimum space a file will take 49 is 32 bytes (this is an empty file, with a less than 16 character 50 name). The maximum overhead for any non-empty file is the header, and 51 the 16 byte padding for the name and the contents, also 16+14+15 = 45 52 bytes. This is quite rare however, since most file names are longer 53 than 3 bytes, and shorter than 15 bytes. 54 55 The layout of the filesystem is the following: 56 57 offset content 58 59 +---+---+---+---+ 60 0 | - | r | o | m | \ 61 +---+---+---+---+ The ASCII representation of those bytes 62 4 | 1 | f | s | - | / (i.e. "-rom1fs-") 63 +---+---+---+---+ 64 8 | full size | The number of accessible bytes in this fs. 65 +---+---+---+---+ 66 12 | checksum | The checksum of the FIRST 512 BYTES. 67 +---+---+---+---+ 68 16 | volume name | The zero terminated name of the volume, 69 : : padded to 16 byte boundary. 70 +---+---+---+---+ 71 xx | file | 72 : headers : 73 74 Every multi byte value (32 bit words, I'll use the longwords term from 75 now on) must be in big endian order. 76 77 The first eight bytes identify the filesystem, even for the casual 78 inspector. After that, in the 3rd longword, it contains the number of 79 bytes accessible from the start of this filesystem. The 4th longword 80 is the checksum of the first 512 bytes (or the number of bytes 81 accessible, whichever is smaller). The applied algorithm is the same 82 as in the AFFS filesystem, namely a simple sum of the longwords 83 (assuming bigendian quantities again). For details, please consult 84 the source. This algorithm was chosen because although it's not quite 85 reliable, it does not require any tables, and it is very simple. 86 87 The following bytes are now part of the file system; each file header 88 must begin on a 16 byte boundary. 89 90 offset content 91 92 +---+---+---+---+ 93 0 | next filehdr|X| The offset of the next file header 94 +---+---+---+---+ (zero if no more files) 95 4 | spec.info | Info for directories/hard links/devices 96 +---+---+---+---+ 97 8 | size | The size of this file in bytes 98 +---+---+---+---+ 99 12 | checksum | Covering the meta data, including the file 100 +---+---+---+---+ name, and padding 101 16 | file name | The zero terminated name of the file, 102 : : padded to 16 byte boundary 103 +---+---+---+---+ 104 xx | file data | 105 : : 106 107 Since the file headers begin always at a 16 byte boundary, the lowest 108 4 bits would be always zero in the next filehdr pointer. These four 109 bits are used for the mode information. Bits 0..2 specify the type of 110 the file; while bit 4 shows if the file is executable or not. The 111 permissions are assumed to be world readable, if this bit is not set, 112 and world executable if it is; except the character and block devices, 113 they are never accessible for other than owner. The owner of every 114 file is user and group 0, this should never be a problem for the 115 intended use. The mapping of the 8 possible values to file types is 116 the following: 117 118 mapping spec.info means 119 0 hard link link destination [file header] 120 1 directory first file's header 121 2 regular file unused, must be zero [MBZ] 122 3 symbolic link unused, MBZ (file data is the link content) 123 4 block device 16/16 bits major/minor number 124 5 char device - " - 125 6 socket unused, MBZ 126 7 fifo unused, MBZ 127 128 Note that hard links are specifically marked in this filesystem, but 129 they will behave as you can expect (i.e. share the inode number). 130 Note also that it is your responsibility to not create hard link 131 loops, and creating all the . and .. links for directories. This is 132 normally done correctly by the genromfs program. Please refrain from 133 using the executable bits for special purposes on the socket and fifo 134 special files, they may have other uses in the future. Additionally, 135 please remember that only regular files, and symlinks are supposed to 136 have a nonzero size field; they contain the number of bytes available 137 directly after the (padded) file name. 138 139 Another thing to note is that romfs works on file headers and data 140 aligned to 16 byte boundaries, but most hardware devices and the block 141 device drivers are unable to cope with smaller than block-sized data. 142 To overcome this limitation, the whole size of the file system must be 143 padded to an 1024 byte boundary. 144 145 If you have any problems or suggestions concerning this file system, 146 please contact me. However, think twice before wanting me to add 147 features and code, because the primary and most important advantage of 148 this file system is the small code. On the other hand, don't be 149 alarmed, I'm not getting that much romfs related mail. Now I can 150 understand why Avery wrote poems in the ARCnet docs to get some more 151 feedback. :) 152 153 romfs has also a mailing list, and to date, it hasn't received any 154 traffic, so you are welcome to join it to discuss your ideas. :) 155 156 It's run by ezmlm, so you can subscribe to it by sending a message 157 to romfs-subscribe[AT]shadow.banki.hu, the content is irrelevant[DOT] 158 159 Pending issues: 160 161 - Permissions and owner information are pretty essential features of a 162 Un*x like system, but romfs does not provide the full possibilities. 163 I have never found this limiting, but others might. 164 165 - The file system is read only, so it can be very small, but in case 166 one would want to write _anything_ to a file system, he still needs 167 a writable file system, thus negating the size advantages. Possible 168 solutions: implement write access as a compile-time option, or a new, 169 similarly small writable filesystem for RAM disks. 170 171 - Since the files are only required to have alignment on a 16 byte 172 boundary, it is currently possibly suboptimal to read or execute files 173 from the filesystem. It might be resolved by reordering file data to 174 have most of it (i.e. except the start and the end) laying at "natural" 175 boundaries, thus it would be possible to directly map a big portion of 176 the file contents to the mm subsystem. 177 178 - Compression might be an useful feature, but memory is quite a 179 limiting factor in my eyes. 180 181 - Where it is used? 182 183 - Does it work on other architectures than intel and motorola? 184 185 186 Have fun, 187 Janos Farkas <chexum[AT]shadow.banki[DOT]hu>