* Increases romfs partition size limit from 2GB to 4GB.* Adds new derivative of romfs filesystem (rom2fs) with block aligned regular file data to bring performance parity with ext2/3. This is about 225% of the read speed of the existing romfs.

diff --git a/Documentation/filesystems/romfs.txtb/Documentation/filesystems/romfs.txtindex 2d2a7b2..170b1cc 100644--- a/Documentation/filesystems/romfs.txt+++ b/Documentation/filesystems/romfs.txt@@ -7,6 +7,10 @@ similar feature, and even the possibility of a smallkernel, with a file system which doesn't take up useful memory from the router functions in the basement of your office.

+The romfs version 2 filesystem is a slight derivation created to fix+performance issues with file data unaligned to logical disk blocks.+It differs only in its placement of regular file data.+ 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@@ -18,7 +22,10 @@ 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.+its mirrors, in the /pub/Linux/system/recovery/ directory, as well as+at the sourceforge project http://romfs.sourceforge.net/ . A genromfs+patch to support version 2 is available at+http://rom2fs.googlepages.com/ .

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@@ -43,6 +50,11 @@ from the network, and you will have all thetools/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 also has a secondary use in reproducibility. The absence of+both timestamps and permission information coupled with the read-only+nature of the file system gives it amazing capability as a byte+reproducible medium for a given directory structure.+ 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@@ -50,7 +62,8 @@ is 32 bytes (this is an empty file, with a less than16 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.+than 3 bytes, and shorter than 15 bytes. romfs version 2 adds+additional overhead in order to align file data to (1k) disk blocks.

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@@ -169,11 +184,12 @@ solutions: implement write access as acompile-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"+boundary, it is currently 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.+the file contents to the mm subsystem. This is addressed by romfs+version 2.

/*- * Ok, we do readpage, to be able to execute programs. Unfortunately,- * we can't use bmap, since we may have looser alignments.+ * romfs version one readpage function. File data is unaligned+ * to logical block, must manually copy to kmap'd page. */