Mistake or not, I'm putting btrfs into production for a couple servers this year. All services (DNS, LDAP, NFS, DHCP) are running inside LXC containers, with b

Mistake or not, I'm putting btrfs into production for a couple servers this year. All services (DNS, LDAP, NFS, DHCP) are running inside LXC containers, with btrfs as the backing store. The idea is to be able to make snapshots of containers, and use btrfs send / receive to sync those with a backup container host. So if the primary fails, the services can be quickly and easily restarted on the backup container host. So far, btrfs itself has been the main source of problems. Out of perhaps unwarranted paranoia, I often configure servers with 3-disk RAID-1 for critical data, so two drives would have to fail before a service interruption or data loss. btrfs doesn't support this... their idea of RAID-1 means that two copies of data exist. On a 3-drive btrfs RAID-1 array, if two drives fail, you are going to have problems. Rebalancing doesn't run automatically upon disk failure either. As a result, I've just gone back to a 2-drive btrfs RAID-1 config. I've had a couple problem with sending / receiving snapshots. These were eventually resolved by back-porting the 4.4 btrfs-tools package. The version in Ubuntu 16.04 should be OK for my purposes, so I won't have to worry about that so much soon. So btrfs may be OK for full production use in 2016, but significant problems exist for people using LTS distributions with older versions of the kernel code and user space tools. But yeah, I'd like to see people just put effort into btrfs, and add the concept of a volume manager to it (like with mdadm when you create an array from /dev/sda1 and /dev/sdb1, it can be named /dev/md0 and you can refer to that as its own thing).