As said earlier, the Factory Live CDs are using clicfs for compression and write access. This has one performance problem: booting on ext3 accesses many different blocks (4096 bytes each) that are on many different places in the file system. Squashfs has a structure that makes it a better fit to livecds as it compresses metadata independent from file data. This doesn’t give you a huge difference, but it’s there. Especially with CDs that are very slow to seek from track to track. Booting the gnome 64bit live cd loads about 177MB (out of >2200MB in total on the CD) when booting into an autologin session. This comes with around 1700 seeks – and one seek can be as slow as of half a second (even though most don’t take that long).

But what’s worse: as clicfs (and squashfs) create larger blocks for gaining better compression (128KB for both), you will in effect decompress way more data than you need – and while the decompression used isn’t a big problem for nowadays computers (and you don’t necessarly expect the live cd to fly on yesterday’s computers), it adds quite a lot to the boot time of the live cd.

As I talked a lot with real file system developers about the problem, a pretty simple idea came up: reshuffle the blocks in a way that they are just in the right order – both within the larger compression blocks as on CD to avoid seeks as much as possible. That’s the reason clicfs and mkclicfs both take a -l option. If you mount the container with -l, it will output things like this to the logfile:


access 0+11
access 189+4
access 32957+4
access 65536+4
access 98493+4
access 131072+4
access 164029+4
access 196608+4
access 229565+4
access 262144+4
access 295101+4
access 327680+4
access 360448+4
access 393216+4
access 425984+4
access 458752+4
access 491520+4
access 524288+4
access 557056+4
access 589824+4


That’s actually the first couple of accesses on booting said live cd. It’s resize2fs that’s reading 16K here and there on the file system – accessing 20 compression blocks, decompressing 132K for each of these accesses. But the good news: if you pass this log file to mkclicfs -l, it will put all these blocks as first blocks while creating the container. Of course you need to make sure both clicfs and mkclicfs are talking about the same ext3 file system, otherwise it will be nonsense data.

So what I do is abusing the build service in a sense. I let kiwi create a live cd with fast compression as first step – fast compression because I’m only interested in the ext3 file system. Then I download and boot these live cds in kvm and grab the clicfs log. These I upload back into the project and as third step I have a package that will depend on the live cds from step 1 and the logs from step 2 to generate the real live cds with good compression.

This makes up for the initial disadvantage in performance – it’s actually the opposite, the factory live booted 12% faster than the 11.1.