Home Home > 2009 > 05 > 06
Sign up | Login

Deprecation notice: openSUSE Lizards user blog platform is deprecated, and will remain read only for the time being. Learn more...

Archive for May 6th, 2009

I got Network!

May 6th, 2009 by

I tried an installing using the USB images on the Acer Aspire One I’m using to test these things (and to test preload on SSD systems).

And I wasn’t able to connect to wifi, because the NetworkManager didn’t want to give out wireless networks to the applets. The reason was in the logs: it thought the radio kill switch was on. But fortunately Helmut gave me the golden tipp:

echo "blacklist acer-wmi" > /etc/modprobe.d/coolo.conf
rmmod acer-wmi
rcnetwork restart

It’s one of these things that frustrate you, because they are very easy to work around if you find the right spot in the internet. And that’s the reason I create this blog entry: to allow the next with the problem to fix his wlan. Happy surfing and thank Helmut not me 🙂

BTW: it’s fixed for newer kernels, but 2.6.30 is too fresh for me.

Profiled Live CDs

May 6th, 2009 by

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.

Rebooting icecream

May 6th, 2009 by

Our icecream scheduler is moved to another room, so I thought I share the statistics
(just telnet <scheduler> 8766)

200-ICECC 0.8.0-make-it-cool: 5261077s uptime, 61 hosts, 0 jobs in queue (53255934 total).

So this is still the pre-0.9 code and it served in 60 days over 10 jobs per second on average.