Wandering Thoughts archives


The timing of production Linux deployments

Yesterday I wrote that even in two or three years, building on btrfs would be risky because we'd probably be one of the early people doing serious production deployments using it. I want to note something related to that statement: what I said has almost nothing to do with how ready or not btrfs will be in two or three years, and everything to do with timing and release schedules.

Production deployments are almost invariably based on Linux distributions with long term support, the most prominent being Ubuntu LTS and Red Hat Enterprise Linux (or CentOS). These distributions have quite long release schedules, so even if btrfs magically got perfect tomorrow, it would likely be years before it would ship as part of such a distribution, much less proven in production.

Well, sure. But how many years?

Per here, Ubuntu does LTS releases every two years. The most recent LTS was released in April 2010, so the next Ubuntu LTS will be released in spring 2012. Red Hat doesn't publicize any release schedule for RHEL, but per the timeline here releases have been running two to three years apart. RHEL 6 was just released at the end of 2010, so the earliest I'd expect RHEL 7 is at the end of 2012 and the end of 2013 seems more likely to me.

Then there are two complications. The first one is that 'available in a distribution' is not the same thing as 'proven in production'. To go from one to the other takes time; it takes a year or two for people to deploy something based on a new distribution and have positive long term experiences with btrfs. So even if a fully ready btrfs was available in 2012, deploying it in 2013 could easily make us one of the relatively early adopters in production deployments.

(Deploying in 2014 would be safer, but I'm not sure our fileserver infrastructure will last that long; the fileserver hardware would be approaching six years old at that point.)

The second complication is that long term stable releases do not use the latest and greatest software versions as of when they're released. Instead they use older versions (often significantly older), because they freeze things months before release in order to have enough testing and debugging time. Similarly, the distributions have to make decisions on what to support and emphasize months before they release; no one is going to add btrfs as a first class, fully supported filesystem at the last moment. So what matters is not btrfs's state right at release, but its state significantly before release.

Pragmatically, I'd expect that btrfs would have to be stress-tested in at least one Fedora or regular Ubuntu release before it would appear as a fully supported feature in RHEL or Ubuntu LTS. This potentially puts another delay in the process, since the Fedora and Ubuntu release managers are not going to do this until they feel that btrfs is pretty ready for the job. This would add another six months or so of delay, since both Ubuntu and Fedora on a roughly every six month release schedule.

(How much actual delay it adds depends on when btrfs becomes production ready relative to the release schedules of RHEL and Ubuntu LTS. If btrfs was magically production ready tomorrow, there would be plenty of time for it to be tested in Fedora and Ubuntu releases before the next version of RHEL and Ubuntu LTS were frozen.)

The corollary of this delay is that if you're seriously considering using btrfs in the near future because you need it, you should be keeping an eye on it now and planning some testing as soon as it looks good enough. Waiting until it ships as part of RHEL or Ubuntu LTS will only cost you time.

(This feels a bit odd for old-time sysadmins. It used to be that the big vendor releases had the newest and best stuff; now in Linux they're months behind the times.)

linux/ProductionBtrfsTiming written at 01:00:55; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.