I think this is a political move disguised as technical move
I think there are solid technical reasons to discourage Btrfs use, just to quote from the official wiki [0]:
> The parity RAID code has multiple serious data-loss bugs in it. It should not be used for anything other than testing purposes.
Now I don't know if this issue has been addressed already, or which kernels are affected, but the fact that there is a prominent warning on the wiki speaks for itself.
Personally, I'm a happy btrfs user deploying a mixed-disk-size array without parity, with the hope to add redundancy some time in the future. Currently, btrfs is the only FS allowing to mix disks of any size and to run an optimal configuration on top of them [1].
The particular bug that sparked that warning was fixed a while ago, but as a precaution against "btrfs ate my data" stories they've removed the ability to create btrfs-raid from the CLI tools (you can still use md RAID with btrfs but you lose most of the benefits of btrfs that way).
The design of btrfs allows for mismatched disks to be used in an array, and the btrfs RAID will keep the right level of redundancy while using the maximal amount of space, e.g. with a 4 TB, 2 TB, and 1 TB drive:
mdadm will give you 1 TB in RAID 1, or 1.5 TB in RAID 10 (constrained by the smallest drive).
btrfs will give you 3 TB in RAID 1 (constrained by the sum of the smallest drives).
btrfs also allows per-subvolume raid policies. So you could, for example, give users an "archive" subvolume in their home directory. You could then mark this as RAID 1 or RAID 5 (because you don't care so much about performance) while the main /home filesystem is RAID 10.
Unfortunately the RAID code is all horribly broken.
Being able to have non-symmetric disk topologies with redundancy. I believe that md raid does not support that, while btrfs multi-device does (which is what I think of as one of the really unique features of btrfs -- not even ZFS can handle the sort of disk topologies that btrfs can).
md-raid absolutely supports that and synology has for a long time. They call it "SHR". You simply do raid over disk partitions to enable disks of disparate sizes.
The reason ZFS doesn't support it, and absolutely 0 enterprise storage devices support this is because as the disks fill up, you sacrifice both performance and redundancy. Synology won't even support it on their high-end devices for this very reason. They'll only do it on their devices targeted at home use.
I think there are solid technical reasons to discourage Btrfs use, just to quote from the official wiki [0]:
> The parity RAID code has multiple serious data-loss bugs in it. It should not be used for anything other than testing purposes.
Now I don't know if this issue has been addressed already, or which kernels are affected, but the fact that there is a prominent warning on the wiki speaks for itself.
Personally, I'm a happy btrfs user deploying a mixed-disk-size array without parity, with the hope to add redundancy some time in the future. Currently, btrfs is the only FS allowing to mix disks of any size and to run an optimal configuration on top of them [1].
[0] https://btrfs.wiki.kernel.org/index.php/RAID56
[1] http://carfax.org.uk/btrfs-usage/