I'm working with FC3 on a development which has to run, in some instances, entirely on RAMdisk, booted off CF.

The simple way, I thought, would be to make the initrd hold the ultimate RFS. This, after I'd done some due diligence on 'maximum initrd size' and came up with postings which suggested that there is no practical limit to initrd sizing except that of physical resources.

I've done a base 'minimum only' install of FC3 onto a HD on the target, then archived off the RFS onto the development machine where I've generated an initrd from it. Even with considerable pruning, it comes in at 61Mb compressed and about 170Mb uncompressed. This *does* load successfully from an ext2 partition on CF onto my 1Gb target, and seems to be fine.

Unfortunately the app requires Apache functionality in addition to the base installation. When I added that in, the compressed size is 104Mb and the uncompressed size is about 290Mb. This is where things go pear-shaped.

GRUB 0.95-3, which loaded the 61Mb compressed image in 25 seconds, took 23 minutes to load the 104Mb compressed image. Some diagnostics showed that the process slowed down dramatically as soon as the block accesses exceeded the inode direct addressing capability, at a little way beyond the 60Mb point.

I assume that the reason the bootloader takes so long handling indirect blocks in ext2 is that it calls for a single block at a time, and that the equivalent functionality in the kernel benefits from reading multiple contiguous blocks where possible. I'd appreciate comment on that assumption!

I've thought of five possible ways forward, but I'm hesitant to choose between them until I've had some feedback from you guys out there :-

(a) find a way to prune the RFS down to around 61Mb compressed (longwinded, tedious, possibly doomed to failure)
(b) use some other filesystem than ext2 on the CF (is there one with higher direct addressing, that GRUB supports?)
(c) change the partition size (in some fstypes this changes the addressing limits, does it do so in the case of ext2?)
(d) import the kernel's more efficient ext2 reading code into GRUB (substantial rewrite)
(e) abandon this usage of initrd and go to a second-stage ramdisk instead

What do people think of the above?

Your best bet is probably to use JFFS2 on the flash. The Journalling Flash Filesystem 2 was pretty made to do exactly what you are describing.

I also recommend using a 2nd stage ramdisk instead of an initrd. Your really going beyond the scope of what initrd was intended for here.

Ta - using a second stage has solved the problem. The 104Mb file unpacks in 75 seconds now - still rather longwinded, but that's just a gzipped tarball, there may be better-time-performing archive methods to be tried.

Not used the Journalling Flash filesystem yet either, that may also improve matters.

Ciao!