tbg nails it, I'd add one thing further, running LUKS ontop of btrfs is just asking for failure, and as PerlMonk observes, failure is what he got. I consider, and again, as Perlmonk notes re the tools 'being worked on' for btrfs, btrfs is in my opinion a beta filesystem which for reasons absolutely a mystery to me is being offered as a stable robust mature filesystem, which it is not. It's not even feature complete yet.
Keep in mind the real history: Oracle, before they bought Sun, started btrfs as a weak attempt to create their own ZFS type file system, but as soon as they bought Sun, development of btrfs was dropped at the corporate level, and after a while, it drifted more into what I'd consider the hobbiest development pool of developers.
If you read the btrfs docs, which I did while looking at extending the inxi --logical/-L feature to support btrfs, you'll see that it's not feature complete at all, and also never achieved maturity before leaving it's funded development at Oracle, I don't believe it was even half done at that point.
I dropped development of full btrfs support as soon as I saw how awful their tools were, it wasn't even a pale imititation of zfs tools, the stuff just is not done.
As far as I can tell, the entire snapshot thing is just a solution to a problem that doesn't exist on a real operating system, failed upgrades, I think that's what it's supposed to solve, but if your upgrades fail, you have an issue with your operating system and package management system, not your file system.
If you're going to run a file system and luks, then keep it simple, run a very stable, rock solid file system, like ext4, and run luks on top of it. When you start injecting more and more software layers between you and your data, you're just asking for failure at some point. I ran extensive vm tests on the most absurd combinations of scenarios when developing the --logical feature (lvm, mdraid, luks, stacked one on top of each other) and by the end of that, I was totally convinced to never do anything like that myself for real data.
I really wish distros would stop marketing btrfs as a robust production ready file system, it does too much, it's too complicated, it's never had the heavy duty development required, and, worst, it has no reason to exist beyond one simple fact: Sun adopted a poison pill defense when licensing zfs, they chose a license that was deliberately incompatible with native linux kernel distribution. That is literally the only reason for btrfs to exist, if that license were to change, there would be essentially zero reason to use btrfs beyond having fun with hobbiest stuff. And OpenZFS has removed even more of those obstacles, though the kernel guys can't directly implement it due to the license poison pill, but it can now be run reasonably solidly, but only with known supported kernels. That is the thing Sun was trying to achieve, no native out of the box linux kernel support for ZFS, and that achievement is still in effect.
Obviously, eventually, with enough users, and enough skilled developers, btrfs may one day become mature and robust enough for real production use, but to me, I'll know that day is nearing when their data and reporting tools stop sucking. That day is certainly not today, which is why you'll find inside of inxi a btrfs data stub, where I'd started initial testing, and gave up, somewhat horrified at the terrible job that had been done on the tools.
Not trying to poke any bears here, I just find it really odd that distros are shipping btrfs as if it were robust and ready for prime time when it quite clearly isn't. Filesystems take forever to get working, I've watched the microsoft corporation fail repeatedly delivering their still not there NTFS replacement, for example, making these things work and be reliable is HARD!!! And MS has 10s of thousands of paid developers, who can, and were, told to make it work, yet still failed to do so. it took forever for ext4 to become stable enough to use, and that was simply an extension of long time stable ext2 and ext3, more in the lines of an incremental development.
I was talking to another developer guy who is fairly close to the kernel guys, while doing the --logical feature, and he noted he has a friend who makes a good living recovering data from these types of failed software based storage systems. Just because something is called a filesystem doesn't mean it's a file system in the sense that fat32, ntfs, ext3/4, xfs, ufs, and so on, are file systems, once you get into something like zfs, you need heavy duty hardcore development dollars, Sun had the talent to do zfs (sun was one of the places to work in silicon valley at the time, which meant that they got the real talent) oracle didn't have that talent, and was and remains a crappy place to work, and came up with btrfs.