Transparent compression.

Subvolumes: "Lightweight partitions" allow you more easily to define the scope of a snapshot. With ext4+lvm you have to create a new partition and logical volume.

I don't think, it is a big game-changer, but then I don't think, the other things are such dealbreakers as many people think. I consider "is more prone to data corruption" as largely historical/anecdotal.

Btrfs send sounds appealing, but personally, I prefer my backup solution to be independent of the filesystem.

When I replaced the SSD in my laptop with a larger one and needed to resize the partition (and filesystem, etc.) to use the capacity of the larger SSD, I had to do that at least on the filesystem, LVM and partition table levels. Or at least I don't think I found any tools that would have done the entire job for me, because I remember doing the layers step-by-step.

If there's no LVM, most point-and-click tools allow for resizing a partition and a contained filesystem in a fairly simple process. (Having a LUKS encrypted volume might complicate that, but if the encryption is on the filesystem level, that could also be avoided.)

People who dual-boot might also need to resize their partitions if their needs regarding the operating systems change, or if they made a mistake in their original allocations.

That's probably not enough of a reason to make a major switch, but it could be one task that could be simplified.

Doesn't gparted do this for you? It will automatically figure even the most complex of operations that require filesystem copy.

I can't remember exactly, as it's been a few years. I'm pretty sure gparted would have been one of the first things I looked into, though.

Looking at my disk in gparted now, while it shows the LVM physical volume (and would presumably allow resizing it if it weren't in use), it doesn't seem to show the logical volumes and their filesystems inside of the physical volume at all. The partition information window for the LVM PV does list the logical volumes, but not the main window where you can plan the changes.

I don't know if that's a general limitation of gparted or if it's a peculiarity with my setup, but that's how it appears to me.

> is more prone to data corruption.

I'd challenge that. The main reason for using btrfs in desktop use is precisely is that your data is less likely to be corrupted. Specifically because unlike lvm+ext4, btrfs does full data checksums and therefore is capable of detecting silent data corruption.

It depends what type of corruption is more likely - silent bit flips in hardware, or a bug in btrfs code.

> requires more ongoing maintenance (scrub, rebalancing)

I'm not sure that's a good description. Scrubbing is an option that you get extra. You don't need to use it and the behaviour won't be different than for example ext4 with regards to bad data detection. It's purely an extra feature.

If rebalancing is useful for desktop users (wasn't really in my experience), I'm sure it will get a system-provided job that balances the resource use and amount of reclaimed space.

There are concerns with ZFS of the "scrub of death" on a system lacking ECC ram:

https://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-y...

There is some debate on this question:

https://arstechnica.com/civis/viewtopic.php?f=2&t=1235679&p=...

I'm curious if the situation is improved for BtrFS.

The first link actually explains why ZFS is no more dangerous than any other filesystem.

honestly, I've only ever needed to rebalance on a desktop system when statfs() returned an f_bavail=0 and some program decided to take this information seriously and refused to write at all. There are still quirks with statfs info coming from btrfs volumes only solved with intense rebalancing.

btrfs supports zero-copy file and block cloning which is very good for some applications, e.g. rr.

I can't speak for everyone, but in terms of administration, it's much easier to deal with than having to sort through the filesystem sundae you end up making with device mapper frameworks and the filesystem cherry on top of it all. In a humorous twist, subvolumes are basically thin provisioned logical volumes too and btrfs still had quotas to make them behave as such.

I use the `lv`, `pv`, and `e2fsprogs` families of commands pretty routinely in my day job (we minimally logical volume filesystems on hosts and leave it up to application/deployment/user what to do with the bulk of the storage) and haven't found this to be a real issue. After a couple minutes thinking about what you're doing, you never really need to revisit this. You should probably spend a few minutes thinking about what you're going to be doing when dealing with your filesystems anyway.

Checksums so I don't backup corrupted data and never notice.

Instant, unlimited, zero-weight snapshots. You'd be surprised how often you use snapshots when you have them. A couple weeks ago I screwed up a save point in a game. Instead of just living with my mistake, I rolled my Steam directory back an hour.

Transparent compression.

Time to resilver a failed disk on btrfs depends on the amount of data on the partition, while the same on lvm is constant on the full size of the disk.