Mistake or not, I&#x27;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.<p>The idea is to be able to make snapshots of containers, and use btrfs send &#x2F; 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.<p>So far, btrfs itself has been the main source of problems.<p>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&#x27;t support this... their idea of RAID-1 means that two copies of data exist.<p>On a 3-drive btrfs RAID-1 array, if two drives fail, you are going to have problems.  Rebalancing doesn&#x27;t run automatically upon disk failure either.  As a result, I&#x27;ve just gone back to a 2-drive btrfs RAID-1 config.<p>I&#x27;ve had a couple problem with sending &#x2F; 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&#x27;t have to worry about that so much soon.<p>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.<p>But yeah, I&#x27;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 &#x2F;dev&#x2F;sda1 and &#x2F;dev&#x2F;sdb1, it can be named &#x2F;dev&#x2F;md0 and you can refer to that as its own thing).