Updating SmartArray controllers on 64-bit Ubuntu 14.04

Want to install a firmware update on one of your HP SmartArray controllers while running a 64-bit OS? Turns out, the binaries distributed by HP seem to be 32-bit only – running for example Ubuntu 14.04, here’s what you gotta do…

 

But libstdtc++6 seems already installed, hmpf… 32-bit maybe?

 

Let’s try that again…

Well, that was rather easy…

The roaring sixties

… when two regular furniture salesmen could just walk into Harrods and buy a lion cub to fool around with.

[youtube https://www.youtube.com/watch?v=ms-piPxEzbk]

Wikipedia has a page about the story/events here. At £3500 / USD 6000 today not exactly cheap and apparently not that uncommon back then, according to the 45-minute full length documentary (which actually paints a slighty different, more realistic picture – worth watching)

Fix check_hpasm for 3.x kernels

After upgrading one of my HP ProLiant servers to Ubuntu 12.04 LTS (better late than never) the check_hpasm Nagios plugin broke, resulting in no regular checks of the internal arrays being performed.

Apparently that’s a known bug with the hpacucli utility doing the actual checks, which can’t uname returning a 3.x kernel version. You can manually fix this by running it like this:

Therefore a quick and dirty fix for check_hpasm would be to open up /usr/lib/nagios/plugins/check_hpasm and go to the part that reads:

and replace the line (553 in my case) calling hpacucli with:

Worked just fine for me.

Grant Williams ASFA 2013 presentation

While this isn’t an economics or investment blog by any means, here’s a nice 30 minute presentation by Grant Williams recently given during the 2013 ASFA conference. Humorous as always and IMHO spot-on, outlining the current state of international financial markets, the current government bond bubble and equity rally of 2013… and how it’s all inevitably going to go down in flames. Very well worth watching, even if you aren’t a investor, trader or otherwise closely associated with the financial markets.

[youtube https://www.youtube.com/watch?v=5A3CoFyi2U8]

Fix for bad write performance with LUKS + RAID5

After setting up a new fileserver with an LUKS encrypted dataset on top of Linux software RAID5 I did some benchmarks and reliability testing before filling it up with “real” data… but it turns out write performance was quite horrible. Only a fraction of what the “raw” RAID5 could do, all while having the CPU mostly idle. So what’s going on?

Apparently only small blocks of data get written to the disks when using LUKS encrypted volumes (mostly default settings) therefore dramatically reducing write performance (figured it out thanks to this) on my RAID 5 volume. Setting the stripe_cache_size from 256 to 8192 increased throughput from roughly 50-70 MB/sec to well above 200 MB/sec.

To permanently set it, so you don’t have to manually adjust it after every reboot, consider setting up a udev rule like this: