Btrfs and LXC are among the most exciting Linux projects in terms of potential and possibilities. Both are actively developed, are backed by influential companies and have been baking for long.

LXC had it's first stable 1.0 release in February 2014 and Btrfs has come a long way (It's still marked experimental) and seeing increased adoption. Phoronix has been benchmarking Btrfs regularly and the performance has seen a steady improvement.

Chris Mason, the Btrfs lead developer, recently joined Facebook where he is presumably set to use Btrfs to address some of Facebook's burgeoning data challenges.

Btrfs has a lot of advanced capabilities that makes it a true next generation file system. Btrfs stands for b-tree file systems and is pronounced butter fs. It's a copy-on-write (COW) files system, which basically means when using identical resources its not necessary to write untill a change is made. We are going to see in a minute how this make a big difference to LXC usage.

A number of distributions are considering making Btrfs the default, its already the default in Open Suse. Ubuntu allows you to install your root partition to a btrfs file system and even helpfully sets up root and home subvolumes. Even Theodore Tso, the respected ext4 developer thinks its a great idea, "It offers improvements in scalability, reliability, and ease of management". Let's look at the key goodies Btrfs enables.

Pooling
Btrfs can pool and manage multiple physical hard disks as one file system

Inbuilt raid
Btrfs has inbuilt raid, that makes raid deployment a simple affair. No more struggling with complex hardware and software solutions and configuration.

Subvolumes
Sub volumes are a core feature of btrfs and enables a number of interesting possibilities. Subvolumes are like partitions that can be mounted or booted independently but far easier to create and manage. For instance sub volumes can be snapshot and cloned in sub seconds. Yes, your multi gigabyte root volume can be cloned in seconds, and takes no extra space! Read only sub volumes can be used as seeds for various deployment scenarios.

Btrfs Send receive
incremental send receive which makes incremental backups of large file systems much easier to manage.

Quota groups
Disk quotas in btrfs is enabled at the subvolume level and is fairly straightforward to use. Users can then place limits on subvolumes.

Inplace ext2/3/4 conversion
Users can easily convert their current installations to btrfs in seconds.

We are only going to cover a fraction of btrfs capabilities in the context of LXC. LXC is file system neutral and doesn't care about the underlying file system but supports a number of file system functions internally so when you create, clone or snapshot containers in a btrfs file system for instance LXC will automatically use btrfs native functions for these operations.

Users may not be ready to go the whole hog to convert their systems to Btrfs but it makes a lot of sense to have at least the LXC folder on a btrfs file system. You can easily format a small partition as btrfs and mount that as your LXC container folder.

Containers in subvolumes
With Btrfs you can create LXC containers in subvolumes. If the lxc-create command detects its on a Btrfs file system it will automatically create the container in a subvolume. You can also specify this manually  by appending the -b flag to the lxc-create command. The -b flag specifies the backing store and in this case we can use it to specify btrfs.

Containers in Btrfs subvolumes gives users a great degree of flexibility. For instance cloning and snapshots becomes near instantaneous and with near zero extra cost in space. In an ext4 or xfs file system an lxc container clone would take the same amount of space as the original container. In a Btrfs file system a subvolume clone does not take up an extra space apart from the differences between the 2 containers. Only the change data or differences between the original is written to disk. This is one of the main benefits of using a copy-on-write (COW) file system like Btrfs.

Backups become easier and you can even take live snapshots of running containers, with the exception of database workloads. You could have for instance have 100 snapshots of a single container and the only extra space used in your btrfs file system would be the differences between the 99 containers and the base. This is extremely space efficient.

For instance if you are provisioning multiple developer, test or production nodes they can all be cloned from a base seed leading to optimum space usage, even better you can snapshot these frequently without worrying about space requirements and get your self a redundant and resilient backup system at zero cost and complexity.