Caroline Keating

She describes herself as

I’m just a girl who likes to tinker on her piano at 2 am and make up stories…

And that's what she did (not at 2 am, though) yesterday in Nürnberg's Musikzentrale in a really great concert.

I'll keep it short, it is hard to put into words anyway, but that really was a touching experience. Maybe even more than last year's Leonard Cohen concert in Berlin.

...maybe it is no coincidence that both are from Montreal?

Now only Christian needs to get the Photos posted on his site...which he finally did. Thanks!

BTW: if you wan to see more great concert photo's, Christian Deckelmann's website is a must. (You'd never guess that he is a (really cool btw) network administrator in real life ;-) )

Improving XFS unlink() performance

I knew for quite some time that XFS has an abysmal performance on huge deletes - e.g. deleting a Linux kernel source tree can take several minutes. But when I had to do multiple images with kiwi yesterday on my relatively new server machine at home, it started to really annoy me, so I invested some time to find out if there is a way to improve the situation.
This is what I started from (numbers are from bonnie++):

/dev/sda1 /space3 xfs rw,noatime,nodiratime,noquota 0 0

Version 1.01d       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
server           4G 69024  31 71616  10 32732   6 75462  39 77511   6 120.9   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16   341   1 +++++ +++   311   1   340   2 +++++ +++   249   1

The first hint I got from a colleague was to use "logbufs=8" mount option. This increases the number of buffers that XFS uses for its log. Whatever that means. At the first try, it did not change anything until I realized that a "mount -o remount,..." was not enough, I had to unmount and newly mount the filesystem with the option to make it work.
This is the result, still not too impressive with regard to delete performance, the difference might be purely statistical noise:

/dev/sda1 /space3 xfs rw,noatime,nodiratime,logbufs=8,noquota 0 0

bonnie++:
Version 1.01d       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
server           4G 66413  31 68420  10 32467   5 76001  40 77143   6 107.2   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16   338   2 +++++ +++   313   1   332   2 +++++ +++   269   1

But the really good results came only after also increasing the logbuffer size with the "logbsize=262144" option:

/dev/sda1 /space3 xfs rw,noatime,nodiratime,logbufs=8,logbsize=256k,noquota 0 0

Version 1.01d       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
server           4G 77932  33 85196  10 32134   6 59205  32 76792   6 184.5   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16  1495   5 +++++ +++   848   2  1468   7 +++++ +++   916   3

Now that's a real improvement and I'll keep it like that.

But beware, there are some caveats:

• The file system has to support the larger buffer sizes, which means you need a sufficiently new kernel. As I am running openSUSE 11.1 on this machine, this is not really a problem, but I had to enable the "version 2 log format" with "xfs_admin -j /dev/sda1" because this partition was created using SLES10 and I am not sure if I still would be able to mount it on an old machine.


• It will use more memory. I guess that it needs at least 2 MB (256kB * 8 buffers) per filesystem, probably more. But on a box with 2GB of RAM, I'll gladly spare that for better performance.

One note: those "measurements" were taken on a Core2 Duo machine using an abit IP35-E mainboard. The used disk drive was my old Maxtor STM3500630A 500GB IDE drive. I did not do any statistical corrections etc., so your mileage may vary.

Cross compilers for openSUSE

Based on Torsten Duwe's great work (currently in the Buildservice in home:duwe:crosstools), which is building but not working 100% correctly, I fixed the powerpc version up (I have no other architecture to test on) and put them into the openSUSE Buildservice in home:seife:cross for now.
Get them from here: http://download.opensuse.org/repositories/home://seife://cross/SLE_11
(don't get put off by that SLE_11, the cross compilers should be pretty system agnostic. For testing I ran them on a SLES10 which is probably older than anything you want to use, and they worked just fine)

Edit: I just found out that this only works because I have a patched rpm on my SLES10 which understands lzma compression. I have added SLES10SP2 to the repository so that pre-LZMA-rpm distributions still can use it.

So if you need a powerpc crosscompiler, just add that repository, install packages "cross-powerpc-embed-linux-gnueabi-binutils", "cross-powerpc-embed-linux-gnueabi-gcc", "cross-powerpc-embed-linux-gnueabi-glibc" and "cross-powerpc-embed-linux-gnueabi-kernel-headers" and you are ready to go.
Make sure that /opt/cross/bin is in your $PATH and configure your project for target "powerpc-embed-linux-gnueabi".

Still TODO: get them into a proper semi-official project.

Oh - and of course I already changed my favourite embedded projects so that they are now able to build with an "external" toolchain ;)

Follow-up: using dialup on 11.1 without NetworkManager...

This https://bugzilla.novell.com/show_bug.cgi?id=429772#c22 is the "official" documentation. It's the same what Marius already wrote in his comment on my last post on the topic, but I'll mention it here again, so that it gets found more easily.

How to get the pipe symbol on a US keyboard?

Yesterday at FOSDEM 2009, I was asked in an interview done by linux-community.de's Nils Magnus, "how do you get the pipe symbol on keyboards without that extra key" (which "international" keyboards have, but US keyboards don't).
Apart from that question being off-topic, as the interview was supposed to be about my netbook talk I had held just before, it's funny that I knew the answer offhand, since I am very often in the situation to use a german keymap on a US keyboard. So here it is:

Copy this into your .Xmodmap:

! use altgr-# as pipe - if i have an US keyboard
! without key 86, i can use this as pipe.
keycode 51 = numbersign apostrophe bar bar bar bar

Then make sure that "Xmodmap ~/.Xmodmap" is run during login. I think this is done by /etc/X11/xinit/xinitrc.common, but don't quote me on that.

So now you have the pipe on "AltGr - #" (On a german keyboard. With the US keycaps it is "AltGr - |", which is not too inconvenient).
The "<" and ">" characters, which are also on this key (again, with a german layout), can be easily be typed by "AltGr - Shift - Y" for "<" and "AltGr - Shift - X" for ">".

Maybe this is helpful to somebody besides me.

Have fun ;)

Using dialup with 11.1 if NetworkManager does not handle your device

In openSUSE 11.1, NetworkManager is supposed to handle all dialup stuff. But, as far as I know, it can not handle e.g. plain old phone modems or dialup via bluetooth (rfcomm).
Unfortunately, if you now try to use the old methods of kinternet, wvdial or Umtsmon, you will find out that dialup will work with these, but you won't get a working resolv.conv and thus no name resolution. The reason is that the netconfig tools, which do rewrite resolv.conf apparently refuse to do that if NETWORKMANAGER=yes is configured in /etc/sysconfig/network/config.
One solution would be to switch to the old ifup method (NETWORKMANAGER=no), but then wireless LAN will basically be unusable.
Another, dirty and hackish solution is this:

Create a /etc/ppp/ip-up.local, containing

        #!/bin/sh
        echo "nameserver $DNS1
        nameserver $DNS2" >> /etc/resolv.conf

and a /etc/ppp/ip-down.local, containing

        #!/bin/sh
        mv /etc/resolv.conf.netconfig /etc/resolv.conf

Make both of them executable. Dial up.

How does it work? The ip-up script gets the DNS servers in its environment. Just before it exits, it calls the ip-up.local script which then appends them to resolv.conf. During ip-down, the netconfig tools notice that the resolv.conf was changed externally and they refuse to touch it. They instead create resolv.conf.netconfig. ip-down.local now just replaces resolv.conv with resolv.conf.netconfig and everybody should be fine again.

To make this hack a bit more robust, you should probably check if the $DNS[12] variables are non-empty before adding them and you should check if resolv.conf.netconfig is newer than resolv.conf before restoring, but I leave that up to the reader.

Oh - and don't forget to file a bug against NetworkManager if it cannot handle your device!

Important Privacy Notice

If you care for your privacy, make sure to always delete /var/lib/zypp/AnonymousUniqueId before using any of the package management tools (YaST2, zypper).