My home server has a LSI megaraid_sas (Dell PERC 5/i) card to manage its stable of hard drives. It should be given more credit for its smarts.

The Linux kernel has a variety of I/O schedulers ("elevators") available. Most of them are tuned to work well if the underlying storage subsystem resembles a plain disk. A plain disk prefers to handle nicely sorted requests so it doesn't have to seek all over the place. But a high-end hardware RAID card is not like that. It can take unsorted I/O and talk efficiently to its private hard drives. In fact, it does a better job. Here's a quick bonnie++ run with the default (cfq) and the trivial (noop) schedulers:

Version  1.03       ------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
super.elastic.or 8G 50565  84 95278  33 38812  12 31639  45 78279   9  70.8   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  1781  34 +++++ +++ 22777  99  4966  93 +++++ +++ 22423  97
super.elastic.org,8G,50565,84,95278,33,38812,12,31639,45,78279,9,70.8,0,16,1781,34,+++++,+++,22777,99,4966,93,+++++,+++,22423,97

Version  1.03       ------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
super.elastic.or 8G 56135  92 123017  43 51806  16 49672  70 166943  22 350.5   1
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16  2634  50 +++++ +++ 22970  99  5227  99 +++++ +++ 23051  97
super.elastic.org,8G,56135,92,123017,43,51806,16,49672,70,166943,22,350.5,1,16,2634,50,+++++,+++,22970,99,5227,99,+++++,+++,23051,97

As you see, the noop scheduler does better than the cfq one, in every test, in some cases drastically. As in that wonderful line from Toy Story, "(Bo:) I found my movin' buddy!".

By the way, a similar argument applies to virtualized guest operating systems running under a host OS. The host is probably in a better position to sort I/O than the guests, so they should also just use the noop I/O elevator.

The gall … EnterpriseDB may be a fine product, but open source it is not. Press releases like this one simply lie, as it is clear from elsewhere that source code is not available to their customers. It is as if Microsoft called Windows an “open source” operating system, merely because it contains some old BSD network code. Appalling.

Like in a few previous years, I dabbled in the annual ICFP programming contest. This year’s was the least enjoyable.

One element of the problem is of course my fault: I cannot spend the amount of time nor organizational cunning to gather up a handy group of helpers. Being a talentless hack doesn’t help either, but ….

• The programming requirements were relatively modest. At least, they were modest in terms of quantity of code required, but the 22 pages of specifications were full of little exceptions and complications. There appeared to be only one algorithmic innovation required – the rest was make-work. Even that innovation (choice of a data structure for DNA storage that allows fast indexing and append/prepend) could be satisfied by a suitable library (e.g., C++ ropes).

• The rest of the task was looking for clues in the 7-megabyte bit stream. It was more like an old slow adventure game (Myst) than a programming exercise. It was slightly more fun than decrypting some ZIP file.

• The task required complete suspension of disbelief – to the point of absurdity. Here’s something supposed to be from outer space, and yet there is embedded english ascii-art text (visible only with a 32-character line wrap); embedded PNG/MP3; a bunch of images including documentation; and even the library of subroutines that constitute the final solution when correctly assembled.

• The “game tree” seems to have been excessively linear – requiring finding a fixed sequence of hidden artifacts before all the necessary pieces were exposed. The score distribution was pretty sad – inverse-exponential – with the vast majority getting past one or two puzzles, earning them 1-2%.

• A bunch of average contestants chantted via IRC throughout the discussion. Those that got some of the hidden data out were mouth-agape at all they found. How clever of the organizers! But they forget that it’s not a symmetric situation. The organizers deliberately put all this stuff there, and built the system to obfuscate it over several months. The delight of finding something hidden does not mean that hiding it was an extraordinary feat. If anything, it suggests that the contestants are more clever, in the same way as cryptanalysis is known to be far more difficult than plopping together your own encryption algorithm.

I look forward to next year’s contest. I’m sure those organizers will learn lots from this one.