atp

I recently wanted to use flowtype.js with wordpress to create a liquid layout for the text as well as the images. Integrating it required a bit of research into how to load javascript into wordpress the 'correct' way. Here's how it fits together.

We recently upgraded to Zimbra 8.6 from 8.0.7. We hit a problem that not even zimbra support was able to figure out. Perhaps its that our Zimbra instance has been upgraded since version 3 (or 4) but it got into a bad state whenever we tried to update the proxy. Here's the solution.

An update to the previous article on btrfs recovery.

This article has been superseded by http://blog.tinola.com/?e=43

 I had high hopes for BTRFS. The brochure was very enticing. Checksums, snapshots, disk management... all good things for someone who fondly remembers the digital advanced file system. Unfortunately the brochure describes something that right now is a construction site.

Lately I've been getting really disenchanted by it. There are several reasons for that, but the general bugginess and instability is the main reason my enthusiasm is waning.

At home I have several filesystems on several hosts that all run BTRFS and filesystem problems are a common occurrence under both light and heavy loads. Even with latest Fedora (21) or latest kernels (3.17.6 at time of writing) on centos the situation has not improved much. It still feels like we're beta testing something which has been rushed to market.

For example running a mac timemachine share via netatalk (for the missus' computer) is a rapid way to kill a BTRFS filesystem. I think its something to do with sparse files. However even bog standard rsync of normal files  has been able to make a small 3 disk raid 1 setup go read only on me fairly rapidly.

Aha - you'll be thinking that this is some dodgy hardware problem and I'm pointing the finger unfairly at BTRFS. Well, that's not the case as I've seen this happen on multiple machines, some running centos+epel kernels and some running Fedora 20/21. Plus it's acted up at work recently too.

Btrfs clearly has "the momentum" and "the mindshare" in linux land. So, I'm now in the awkward position of not trusting my data to the officially sanctioned future. The alternatives are very unappealing.

EXT4 is solid, but based on old technology.

ZFS brings too much baggage. It'll be probably what I use next out of sheer desperation. 

XFS is looking tired. Its a first generation journal based file system lacking some of the modern conveniences. Percona say it's faster for databases. There's freeze and some other good stuff, but none of the killer features. Its basically just a better ext4.

Personally I think the decision to make XFS the default FS for redhat is very telling. BTRFS is not there yet, they also don't like the baggage of ZFS - plus it also conflicts with their NIH mindset. XFS offers improvements over EXT4 but they're marginal.

Even Jolla only use btrfs for /home, and ext4 for the important partitions (as of u10 vaarainjärvi)

It seems that everyone is waiting for BTRFS to grow up.

In the mean time, here's my recovery steps for a corrupted BTRFS filesystem.

I wonder how hard it would be to add checksums to advfs...

In 2011 I put out an example php class that could be used to talk to the LMAX API protocol. It was incomplete and for illustrative purposes only. It remains that way. Over the years however there have been some improvements and it can now be used for placing, closing and cancelling orders. I've made the latest version available on github, just in case the handful of people who have contacted me over the years about it find it useful to have the latest version. 

Here is the lmax-php-api github repo. As well as the original ticker app, there's a small example web app that shows how to get and handle position state events, as well as the example that forms the rest of the post. 

Its not under active development. Its not supported, and should not be used for real trading - its purely an educational tool. However if you send me a patch I'll probably add it in.

I took the time to start using Mike's HDR histogram port to C the other day. It was pretty painless to use, once I'd overcome a couple of initial problems. One of which is that the C compiler I have on CentOS 6.4 was too old. So I came up with a workaround for older compilers/machines. 

HDRHistogram is Azul's high dynamic range histogram. The readme on github explains what it is. Suffice it to say that I'm in the process of dumping the various implementations of histogram code I've evolved over the years in favour of this for latency and performance management.

Last week we had several reports of disconnections to some of our haproxy fronted services after we upgraded to a longer/stronger SSL certificate. As the version of haproxy we are running is quite old, we tried an upgrade to the latest (dev21). This fixed the disconnections, but after a few packets, it reliably crashed on the production systems. However

we could not repeat the problem on any test or development systems, even through kickstart and puppet ensured they were identical to production. 

This post details how we found the cause of the problem, so I have a record/teaching aid.

Some of these are hard to google for and I've used more than once now, so to save time I'm bookmarking them here.

1. Setting watch points in gdb
2. Displaying the whole string in gdb
3. Setting gdb to break at a particular file/line
4. Setting the coredump limit of a running process to catch a core

None of this is rocket science, but still useful.