For a while now, unclean shutdowns have a very high chance of making btrfs fail on first mount attempt at next boot, with "open_ctree failed" and no other error. May 3 21:54:39 cerebro kernel: [ 300.959175] BTRFS info (device dm-11): disk space caching is enabled May 3 21:54:39 cerebro kernel: [ 300.959874] BTRFS info (device dm-11): has skinny extents May 3 21:54:39 cerebro kernel: [ 300.976649] BTRFS error (device dm-11): open_ctree failed Simply reissuing the exact same mount command (or rebooting for another attempt) "fixes" this, and the mount(s) succeed from then on, as normal, with no visible data loss or other problem: May 3 21:54:39 cerebro kernel: [ 354.553949] BTRFS info (device dm-11): disk space caching is enabled May 3 21:54:39 cerebro kernel: [ 354.554763] BTRFS info (device dm-11): has skinny extents It seems to happen almost always for filesystems on dmcrypt+dmcache, but I have seen it on my ssd with just dmcrypt as well (all disks have write-cache disabled, and the unclean shutdown can be simulated by pressing reset, so unlikely a power-outage problem).
PS: it can also happen when I manually simulate a crash by destroying the dm-cache table entry, which makes it even less likely to be a hardware/sync problem as device mapper should atomically cut off all the devices from btrfs with no low-level data loss.