Most users when talking about BTRFS they usually care about following things: data integrity protection (bit rod protection), snapshots and integrated volume management.
The volume in DSM is built on top of disk group, which takes care of redundancy. That nullifies the BTRFS-integrated volume management and ability to add/remove devices from the volume. DSM comes with SHR, which provides some of those features too - but not as flexible as BTRFS.
A slightly different way of defining volumes would need to be introduced to leverage BTRFS here. Additional options for RAID level when would work great: one would create a BTRFS diskgroup and volumes inside it - implemented as BTRFS subvolumes. Creating a BTRFS volume on top of RAID diskgroup does not bring many features, except for immediate snapshots. This has however one disadvantage - one cannot create effective LUNs on top of such BTRFS diskgroup...
So, currently BTRFS sees only one block device. Now, if one wants to guarantee the integrity, a RAID1 profile for both data and metadata would have to be used in BTRFS, reducing the usable capacity by 50% - all on top of already redundant raid. Unfortunately BTRFS does know nothing about the underlying hardware, so it cannot utilize it more efficiently.
Snapshots are still there, regardless of the underlying layer.
So, it seems the support for BTRFS in 5.2 does not make much sense at the moment. I trust that DSM 6.0 will come with much more comprehensive support, with post 3.19 kernel as well.
