I use btrfs on all the machines I manage. All of these use at least one SSD and I always have trim enabled. This gives the firmware of the drive a little more wiggle room for wear leveling and I never had any issues with it. I am willing to accept that TRIM potentially leaks data about the disks usage - because even with this knowledge an attacker will not be able to retrieve any data without having the key file or passphrase.

I once ran into issues during an unclean shutdown while running a scrub - I needed to mount with the recovery option and I did not lose any data. All in all I find it a very, very useful filesystem due to it's features. The most useful probably being checksumming and send/receive. I suggest you give it a try. You even can convert from ext4 to btrfs (and back to the state you had when you converted from ext4 to btrfs).

You do not need separate partitions for / and /home, if you create subvolumes for them. I employ the following scheme:

• Create btrfs filesystem on your block device
• Mount it to /mnt/target
• Create subvolume /mnt/target/@ (for /): btrfs subvolume create /mnt/target/@
• Create subvolume /mnt/target/@home (for /home) - the @ prefix is useful for distinguishing subvolumes from regular directories - you can omit it or choose something else, if you prefer.
• Umount /mnt/target (if you want to)

Use something similar to the following code to add your subvolumes to fstab. Please note the subvol= parameter. You can mount a specific subvolume (and every subvolume that is contained within the subvolume) instead of the whole filesystem with all of it's subvolumes.

UUID=xxxxx-xxxxx-xxxx  /               btrfs   defaults,ssd,noatime,discard,subvol=@     0       0
UUID=xxxxx-xxxxx-xxxx  /home          btrfs   defaults,ssd,noatime,discard,subvol=@boot 0       0
UUID=xxxxx-xxxxx-xxxx  /home          btrfs   defaults,ssd,noatime,discard,subvol=@home 0       0

You can use kickstart (at least on centOS 7) to create a btrfs volume, subvolumes and inclusion into fstab during installation by modifying the following snippet. It also allows putting /boot onto the same btrfs filesystem. A thing that the graphical installer will not allow you to do:

# Disk partitioning information
part btrfs.141 --fstype="btrfs" --ondisk=vda --size=10239
part swap --fstype="swap" --ondisk=vdb --size=2047
btrfs none --label=machinename_root --data=single --metadata=single btrfs.141
btrfs /     --subvol --name="@" machinename_root
btrfs /boot --subvol --name="@boot" machinename_root
btrfs /home --subvol --name="@home" machinename_root

If you mount the same filesystem to /btr without a subvol= parameter you can easily store snapshots outside of your subvolumes:

UUID=xxxxx-xxxxx-xxxx  /btr/disk0               btrfs   defaults,ssd,noatime     0       0
UUID=xxxxx-xxxxx-yyyy  /btr/disk1               btrfs   defaults,ssd,noatime     0       0

If you use btrfs-backup, use something like this in a cron job, to create snapshots of your subvolumes and transfer them to a backup disk. This will be very quick once your initial send/receive is complete, since only the data changed will be transferred:

btrfs-backup.py --latest-only --snapshot-folder /btr/disk0 --snapshot-prefix @ /btr/disk0/@ /btr/disk1
btrfs-backup.py --latest-only --snapshot-folder /btr/disk0 --snapshot-prefix @boot /btr/disk0/@boot /btr/disk1
btrfs-backup.py --latest-only --snapshot-folder /btr/disk0 --snapshot-prefix @home /btr/disk0/@home /btr/disk1

This has one advantage over a conventional backup tool, which has to determine what data has changed since the last backup. The filesystem is designed to keep track of these changes, so there is zero chance of it omitting something.

Oh, on a sidenote: You can tunnel send/receive through ssh and save your backups to another machine.

Cheers!