Software and hardware annotations 2009 December

This document contains only my personal opinions and calls of judgement, and where any comment is made as to the quality of anybody's work, the comment is an opinion, in my judgement.

[file this blog page at: digg del.icio.us Technorati]

091225 Fri Comprehensive BTRFS vs. others benchmarking

In a thread about some meaningless file system benchamrks Theodore T'so posted a link to a rather comprehensive set of recent file system benchmarks comparing BTRFS with various other Linux file systems (ext3, ext4, JFS, XFS). Trusting his judgement that the benchmarks had been setup in a sensible way I had a look. The tests seems interesting, as they are about various mass operations with either a largish RAID or a single disk, and with 1, 8 or 32 or 128 threads.

The overall impression I get is that JFS and XFS are still overall top choices, with ext4 and BTRFS being much better for the 128 thread case when writing. BTRFS also is by a large margin the most CPU intensive implementation, and sometimes the amount of CPU required to run it seems Something that astonished me was that while XFS outperforms JFS in some cases with high parallelism, that is not by much. Which confirms my opinion that JFS is the best overall default filesystem.

091224 Thu RedHat makes clear again who the competitor is

As I weas reading about the Red Hat Summit 2009 concluded some time ago, I read also the propaganda written on it by their VP OSA Dr. Michael Tiemann, and I was amused to see how clearly and determinedly he speaks of Sun Microsystems rather than Microsoft as their main competitor:

Last year we received a report from a large commercial (not investment) bank about their experiences migrating a significant J2EE application from Unix to Linux. They reported to us several facts: (1) performance improved 6x versus Unix on a specific application (2) the improved performance reduced a key performance metric from "unacceptable" to "exceeds requirements," (3) costs could be reduced by more than 30% the first year and by more than 60% over three years, and (4) the cost effect of Red Hat Enterprise Linux in the context of their overall hardware and software costs was less than the cost of changing money from one currency to another at a typical foreign exchange counter.

the point of the speech was that when new technologies come along that offer tremendous value compared with conventional technologies (in this case, Linux on commodity hardware versus proprietary Unix on proprietary hardware),

One of the ironies here is that Sun have become of the most significant contributors to free software with both OpenJAVA and most notably OpenSolaris itself, which is a very good and credible alternative to GNU/Linux itself.

However as a smart friend once observed the biggest saving some companies have when switching from Solaris to GNU/Linux is in the ability to switch from Sun Microsystems hardware to Dell (or other mass-market) hardware which is not premium-priced. In effect Red Hat is just an enabler for the commoditazion of server hardware, as for most purposes Solaris and GNU/Linux are effectively equivalent.

091211 Fri The case against TCP segmentation offloading

One of the most important aspects of TCP is packetizing a stream of bytes into IP datagrams and this is a congestion control issue. TBC.

091210 Thu Collating order for English not the same as ASCII

A colleague was recently perplexed as the results of sorting a file in a cron script were different from sorting from an interactive shell. Since I had already noticed a similar case, I could reveal that this is due to the locale and in particular the collating order as that for the default C locale is not the same as that for the en locales (in particular as to whether some symbols precede or not alphabetics), and by running the script under cron the locale's collating order would default to C and interactively it would be set to one of the english language locales, in his case it turned out to be the en_US locale.

There is a wider message here, and it is that one limitation of UNIX-like operating systems is that it is difficult to have global state: if state is in the environment all state is inherited from a common ancestor, and if it is in a file the file needs to be reread every time it is modified. Either way specific actions need to be taken to keep state current, and in the particular case the state initialization for processes descended from interactive logins was not happening for processes descended from cron.