Category Archives: Linux

Linux and Open Source

Jaunty gotchas..

Posted on by

A couple of things to be aware of before you upgrade to Jaunty (9.04)..

  • Amarok v1 has been dropped, so if (like me) Amarok2 doesn’t do all you need with iPod’s, etc, then you’ll need Bogdan Butnaru’s Amarok 1.4 PPA to get the classic version for Jaunty.
  • Currently there are issues with MytTV and ATI cards in Mythbuntu (and presumably all other Ubuntu variants) where it won’t display fonts, there’s a Launchpad bug for it and a proposed fix in Mesa waiting for approval at present. The work around is to disable DRI in you xorg.conf for the ATI card, or you can add Mario Limonciello’s PPA containing Mesa builds with his proposed fix.

Other than that I’ve been happily running Jaunty on a number of boxes for a while and it’s been pretty painless so far – though I’m using the mainline kernels on all of them.

Default ext3 mode changing in 2.6.30 (updated)

Posted on by

Here’s something for Linux users to be cognisant of – the default mount option for ext3’s journaling is going to changing from “data=ordered” (i.e. data is committed to disk prior to its metadata) to “data=writeback” (i.e. file metadata may be committed to disk before the file data is). This may be down to Ted Ts’o’s fixes for ext3 fsync() latency in that mode which spawned a long thread on the ext4 list.

Update: apparently Ted floated the idea at the 2009 Linux Storage & Filesystems Workshop, in his session “fsync(), rename(), barriers” – the LWN article notes it made people nervous, saying:

This idea was received with a fair amount of discomfort. The data=writeback mode brings back problems that were fixed by data=ordered; after a crash, a file which was being written could turn up with completely unrelated data in it. It could be somebody else’s sensitive data. Even if it’s boring data, the problem looks an awful lot like file corruption to many users. It seems like a step backward and a change which is hard to justify for a filesystem which is headed toward maintenance mode. So it would be surprising to see this change made.

It was later followed by the post script: “[After writing the above, your editor noticed that Linus had just merged a change to make data=writeback the default for ext3 in 2.6.30. Your editor, it seems, is easily surprised.]“.

Given the massive filesystem thread I guess this is going to make for more interesting times on LKML.. ;-/

Update 2: Forgot to mention too that the relatime option will be the default in 2.6.30, so by default the access time of a file will no longer be updated for every read.

RIP SGI – now owned by Rackable Systems

Posted on by

Silicon Graphics (SGI) is no more, they filed for Chapter 11 bankruptcy protection on April 1st and have just been bought by Rackable Systems. I don’t think this is an elaborate April Fool (and if it was I think the SEC might have a thing or two to say about it). Both Rackable and SGI have identical press releases (Rackable PR – SGI PR) on the transaction for a mere US$25 million.

FREMONT, CA and SUNNYVALE, CA., April 1, 2009 – Rackable Systems, Inc. (NASDAQ:RACK), a leading provider of servers and storage products for medium to large-scale data centers, today announced its agreement to acquire substantially all the assets of Silicon Graphics, Inc. (SGI) (NASDAQ: SGIC) for approximately $25 million in cash, subject to adjustment in certain circumstances, plus the assumption of certain liabilities associated with the acquired assets.
[…]

Rackable has signed an Asset Purchase Agreement to acquire substantially all the assets of SGI, and to assume certain liabilities relating to the assets, pursuant to Chapter 11 of the U.S. Bankruptcy Code, under which SGI filed its petition in New York on April 1, 2009

I guess it’s better than SGI going under completely, but there’s going to be a number of customers now rather worried about their investments..

Sensible talk on patents from ZDNet

Posted on by

Like many western nations that built up their industries under protective laws and now demand that developing countries remove restrictions that they relied on we see Microsoft doing much the same with Tom Tom, as ZDNet points out when discussing why Microsoft are eager to avoid talking about the details of their patent case..

The TomTom claims cover such things as a multitasking computer on which you can run programs, in a car. A wireless Internet-connected computer, in a car. And how to create long file names in the MS-DOS filing system–a fix introduced in Windows 95 because MS-DOS is a direct descendent of 1974’s vintage 8-bit CP/M operating system. A direct descendant? More a bastard child: MS-DOS helped itself freely to many of CP/M’s design concepts, in some detail. But those were the days when Bill Gates could say that software patents had the potential to put the industry at “a complete standstill” and with good reason. If the sort of protection Microsoft now claims for itself had been available to CP/M then, Microsoft would never have created its monopoly, nor amassed a fraction of its power.

Hopefully Tom Tom now being a member of the Open Invention Network will give Microsoft pause for thought. As regards how the system currently works, I cannot put it better than how ZDNet sum it up:

The patent system is not just broken, it is poisonous. It works by fear, using the civil courts as cudgels in the hands of bullies.

Sadly I suspect it’s unlikely to change in the near future.. 🙁

Comparing Fortran Compilers

Posted on by

I’m just testing out the Fortran 90 compilers on our AMD quad core cluster Tango based on some code that Joe Landman wrote as a test case in January 2008, using the same input file as him. The compilers I’m using are GCC 4.3.3, Intel 11.0.81 and PGI 8.0-3.

For the unoptimised (-O0) version I get:

  • GCC: 1.884s
  • Intel: 3.891s
  • PGI: 1.170s

For basic optimisation (-O) I get:

  • GCC: 1.617s
  • Intel: 3.515s
  • PGI: 0.954s

Cranking up the optimisation to -O2 sees no change:

  • GCC: 1.610s
  • Intel: 3.514s
  • PGI: 0.954s

Now we add compiler specific flags:

  • GCC (-march=amdfam10 -O3): 0.956s
  • Intel (-fast): 3.507s
  • PGI (-fast -tp shanghai-64): 0.997s

That got me wondering which had the greater impact, -O3 or the -march=amdfam10 and the result was surprising:

  • GCC (-O3): 1.611s
  • GCC (-march=amdfam10 -O0): 1.238s

So that’s pretty conclusive, just enabling the AMD k10h CPU (i.e. Barcelona/Shanghai processors) with no optimisations gives a better speedup than the highest level of optimisation! Of course it’s better with both, as you can see from the previous set of results.

I’m *really* impressed by GCC’s performance there, as well as the PGI unoptimised speed, and disappointed by the Intel compilers general lack of performance. I suspect Intels answer would be (not unreasonably) that they don’t necessarily target performance for their competitors CPUs.

Grub in Lenny won’t boot when the kernel is on disk 26 or more

Posted on by

Will hopefully get to report this tomorrow to the Grub folks and the Debian maintainer, but basically it looks like the grub in Lenny can’t cope with systems with lots of disks. We have two storage systems that we use software RAID on and seem to have hit a few problems with grub.

  1. grub-mkdevicelist only iterates over the first 16 SCSI drives, so if your boot partition is beyond /dev/sdp then you’ll get an error about it not being able to find the boot partition. This is hard coded into a loop in grub-mkdevicelist.c so you can tweak that up to 25 disks safely.
  2. if you have more than 25 drives (as we do on one system) you’ll hit the next problem as your devices start getting called /dev/sdaa, /dev/sdab, etc.. grub-mkdevicelist doesn’t handle that correctly. If you bump the number in that loop beyond 25 as it will start trying to find /dev/sd{ , /dev/sd| , etc, which it then rejects as they don’t exist. Again that’s fairly easy to work around with a conditional check in get_scsi_disk_name() to at least cope with the sd?? pattern (Reported as bug #514967). This then leads to the last problem of..
  3. Even having the correct device map when your boot device is on /dev/sdab1 still results in Grub in Lenny not being able to locate the boot partition, and we’ve not had time to chase that down any further (reported as bug #514976).

Comments of the type “serve you right for having too many disks” will be ignored.. 😉

ENOKOGAN – Kogan Agora is dead (for now)

Posted on by

Oh well, so much for the dream, this was on the Kogan blog this afternoon:

I’m disappointed to have to tell you that the Kogan Agora has to be delayed indefinitely. This delay comes due to potential future interoperability issues.

Sounds like this was partly due to wanting to keep the device compatible with future Android versions needing better screens:

One of the potential issues is the screen size and resolution. It seems developers will be creating applications that are a higher resolution than the Agora is currently capable of handling. […] In order to fully appreciate the feature-rich applications Android developers will be creating in coming months and years, the Agora must be redesigned.

I hope that whatever they come up with still has a real keyboard..