I think you’re going to get a wide variety of responses here. It comes down to a lot of factors.
For me personally, I’ve been shifting everything I have to Btrfs, so I can tell you what I’ve done recently and why.
A big caveat is that many of my systems have multiple physical drives. This means I’m often setting things up based on the speed and capacity of those disks.
But, I do have one system with a single drive shared for booting, root, and home. It’s set up like this:
A FAT32 partition for /boot. 512 MB.
A single Btrfs partition across the rest of the drive.
Btrfs subvolumes: @ mounted at /, @home mounted at /home. @snapshots mounted at /.snapshots.
I could go crazy with other subvols (e.g. for /var/log), but ultimately it is sufficient for me to be able to snapshot / and /home separately.
For some of my other systems, I’ll have / and /home on different drives. In that case, each has their own @snapshots with their own mount point. I tend still to throw the EFI boot partition mounted at /boot on the same drive as /.
It’s very easy to simply change /etc/fstab as needed and point to another snapshot, effectively rolling back the drive to some former point as necessary.
Fair, I’ve not had any issues but I’m sure they exist. One or the other is faster based on workload, too, so it’s not really that one is objectively better all the time.
I’m sure a lot of them existed 10 years ago but today it is a really good FS. I’m using btrfs on my server and laptop for a few years and had 0 issues. Today’s opinions on largly btrfs base on bugs and FUD from the past which is a shame.
tbh I’m pretty sure the issue I ran into was user error anyways, but once I finally figured out what I was doing, I decided to land on xfs for root and btrfs for home for the following reasons.
xfs is supposedly more performant and common in data centers
having a separate partition mounted at /home allows for os reinstalls or even distro swaps while retaining my home directory contents (assuming my user is the same)
most of the contents I want backed up are held in /home. I don’t want snapshots of my entire system laying around
I think you’re going to get a wide variety of responses here. It comes down to a lot of factors.
For me personally, I’ve been shifting everything I have to Btrfs, so I can tell you what I’ve done recently and why.
A big caveat is that many of my systems have multiple physical drives. This means I’m often setting things up based on the speed and capacity of those disks.
But, I do have one system with a single drive shared for booting, root, and home. It’s set up like this:
A FAT32 partition for /boot. 512 MB.
A single Btrfs partition across the rest of the drive.
Btrfs subvolumes: @ mounted at /, @home mounted at /home. @snapshots mounted at /.snapshots.
I could go crazy with other subvols (e.g. for /var/log), but ultimately it is sufficient for me to be able to snapshot / and /home separately.
For some of my other systems, I’ll have / and /home on different drives. In that case, each has their own @snapshots with their own mount point. I tend still to throw the EFI boot partition mounted at /boot on the same drive as /.
It’s very easy to simply change /etc/fstab as needed and point to another snapshot, effectively rolling back the drive to some former point as necessary.
I’ve had some wild issues that I can’t even begin to explain with btrfs. I landed on using xfs for / partition and btrfs on /home
Fair, I’ve not had any issues but I’m sure they exist. One or the other is faster based on workload, too, so it’s not really that one is objectively better all the time.
I’m sure a lot of them existed 10 years ago but today it is a really good FS. I’m using btrfs on my server and laptop for a few years and had 0 issues. Today’s opinions on largly btrfs base on bugs and FUD from the past which is a shame.
Except RAID5 and 6. Don’t use them with btrfs :)
tbh I’m pretty sure the issue I ran into was user error anyways, but once I finally figured out what I was doing, I decided to land on xfs for root and btrfs for home for the following reasons.