A Random Walk

Have a long running script or command? Would you like to know where it’s spending its time?

The tool to use is ts which is distributed as part of moreutils.

If you’re using a Red Hat product (Fedora / Red Hat Enterprise Linux, CentOS, etc) you can get the ts command by installing the moreutils rpm via yum.

yum install moreutils

Usage is simple. Pipe the output from your script/command to ts and, optionally, supply a format spec. The example below is the hour of the day (%H – 24 clock), the minute (%M), and the second with microsecond fraction (%.S). I added the pipe (|) just to make the output easier to read.


$ ping google.com | ts '%H:%M:%.S |'
18:51:47.874676 | PING google.com (74.125.227.96) 56(84) bytes of data.
18:51:47.874889 | 64 bytes from dfw06s16-in-f0.1e100.net (74.125.227.96): icmp_req=1 ttl=55 time=18.0 ms
18:51:48.860208 | 64 bytes from dfw06s16-in-f0.1e100.net (74.125.227.96): icmp_req=2 ttl=55 time=16.3 ms
18:51:49.862409 | 64 bytes from dfw06s16-in-f0.1e100.net (74.125.227.96): icmp_req=3 ttl=55 time=17.0 ms


Grub2 (currently v1.99) allows for booting from mdraid devices. That’s the good news. The bad news is that its auto-detection mechanism cannot differentiate between whole disk raid devices and raid partitions that end at or near the last sector of the disk when version 0.90 superblocks are used.

The problem is that a version 0.90 superblock is placed at the end of the device (disk or partition as the case may be) and if you have a partition at the end of the disk then both the disk and the partition would use the same superblock location.

Version 1.x superblocks are more sophisticated and no such ambiguity is possible, so we’re just concerned about legacy 0.90 superblocks.

Why should you care? You will care because grub2 will fail to boot, telling you something like:

error: superfluous RAID member (2 found)

What can you do about it?

1. Convert to version 1.x superblocks. There is no direct way to do this and the methods that do exist are risky and will not be discussed here.
2. Properly position the end of your partitons

Option #1 is too risky (for most) so option #2 is your best bet.

Superblock Location

The superblock is 4K long and is written into a 64K aligned block that starts at least 64K and less than 128K from the end of the device (i.e. to get the address of the superblock round the size of the device down to a multiple of 64K and then subtract 64K). The available size of each device is the amount of space before the super block, so between 64K and 128K is lost when a device in incorporated into an MD array.

What should the last sector of the last partition be?

Example: 2TB drive with 3,907,029,168 sectors

Last 64K aligned sector: trunc(3,907,029,168 / 128) * 128 = 3,907,029,120
Start of whole disk superblock: 3,907,029,120 – 128 = 3,907,028,992
Last sector before whole disk superblock: 3,907,028,992 – 1 = 3,907,028,991

If your last partition ends on sector 3,907,028,991 you will not suffer from superfluous RAID members.

Of course, if you have an existing array you will probably need to shrink the array then drop, fdisk, then re-add each member one at a time.

There has been much chatter and complaining about the “PenTile” displays used by Motorola in their latest phones. I decided to break out the old microscope to see what the big deal was all about.

The photos above are of the digits of the time display in the notification area at the top. The photo on the left is the Droid 3 and the right is the Droid 1. The Droid 3 utilizes four squares of (cw from upper left) Red, Green, White, and Blue. The Droid 1 utilizes three vertical bars of (left to right) Red, Green, and Blue.

PenTile Reference: www.nouvoyance.com/technology.html

I just recently replaced my quad-core Phenom II x4 955 with a hexa-core Phenom II x6 1090T. The ‘T’ designation in the model number indicates that the processor supports AMD’s Turbo Core functionality which allows the processor to ‘overclock’ up to three cores under certain circumstances. The default maximum core clock is 3.2GHz, but when three or more cores are idle, Turbo Core can boost the remaining cores to 3.6GHz. Read more on Turbo Core here.

Linux kernel 2.6.33.3 and the 1090T do not play nice together. The powernow-k8 driver does not properly detect cpu speed p-states. A kernel patch has been committed to address this (see this). Linux Magazine has an article that describes the problem, and the upcoming patch, and recommends disabling Cool’n'Quiet until a patched kernel is released.

UPDATE: Kernel version 2.6.33.4, released Wed May 12 2010, resolves this issue.

Continue reading ‘Powernow-k8 AMD Turbo Core Bug’ »

Linux Magazine has a few interesting articles relating to filesystem journals, internal and external, and how metadata performance is affected.

• Size Can Matter: Improving Metadata Performance with Ext4 Journal Sizing – Part I
• Size Can Matter: Ramdisk Journal Metadata Performance – Part 2
• Size Can Matter: Would You Prefer the Hard Drive or the Ramdisk this Evening? Part 3
• Harping on Metadata Performance: New Benchmarks

Continue reading ‘Journals, Metadata, and Performance’ »

There is a post by Endre Stølsvik entitled Linux Java Thread Priorities workaround that is definitely worth a read.

A few years ago I attempted to make use of low priority background threads to use idle cores to offload work. I quickly found that setting java thread priorities has no effect when running on Linux. Being unaware of workarounds, I abandoned the idea.

My solution was to manage the priority of individual work units by feeding small(ish) operations into a queue and starting (n) worker threads to service the queue. This worked well for non-blocking work (nio) but failed miserably for work that required blocking i/o.  Ideally, it would be possible to have a very low priority thread that runs mostly during periods when  other threads are blocked on i/o. Endre Stølsvik’s workaround should almost certainly make this possible.

The Problem

RAID level 5 (and 4 and 6) suffers from poor write performance due to the need to recalculate parity. Writes smaller than (n-1) * chunk size will necessitate that the the remaining chunks be read in order to compute a new parity chunk. This read-modify-write requirement significantly reduces performance for all non large sequential writes. To add insult to injury, the additional seeks necessary to read the missing chunks adds further I/O load which will slow down random reads. During periods of high write load, concurrent reads will suffer.

Continue reading ‘Linux Raid5 + Journal on SSD = Speed — Part I’ »