My bad.
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.
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/