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...

php api revisited.

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.

leading zeros - builtins and FFSL

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.