They’re using XFS. And the reason is the Red Hat have LVM and XFS developers and no Btrfs developers. Fedora has several active Btrfs developers so we’re able to get issues attention, but we need a bug report to track these things and get them worked on upstream, which is the Fedora way of things.
Fedora doesn’t install Timeshift by default. To use it requires non-standard configuration to meet Timeshift’s hardcoded requirements. So I’m not sure how opting into such a setup makes Btrfs complex.
As it’s implemented in Fedora it’s just a drop-in replacement for ext4, we’re not doing any snapshots. There shouldn’t be differences between df and btrfs filesystem df, or du and btrfs filesystem du. Those btrfs specific tools show extra information, but should still be consistent with the existing tools, when used in the default configuration.
Anytime there’s departure from the defaults, taking advantage of sophisticated features that don’t exist on other filesystems, it’s true there can be more complexity. But we’ve tried to take advantage of features that don’t burden the user with jargon or feeling like they have to use features.
e.g. you’d only ever need btrfs device subcommand if you’re working with more than one device in a Btrfs pool. There’s no equivalent for that on ext4, it doesn’t support multiple devices or storage pooling. You can get that with LVM, but then you have to learn a bunch of LVM commands. If you prefer LVM, you can use it instead, it’s not a problem.
Anyway, I don’t think it’s consistent to say Btrfs is complex and LVM is not complex. Or that Btrfs is complex because it has a bunch of features I’m not using. Or that Btrfs is complex because I’m using features no other file system has.
The one complexity regular Fedora users might encounter is the discrepancy resulting from compression. File sizes are still reported as uncompressed, but then used vs free space suggests less space is being used. There isn’t yet a btrfs subcommand for learning about how much a file has been compressed. We ship compsize by default for this, you can point it to a file or a directory or a subvolume and it’ll give you some extra details about such things if you want.
But for most users, I think they expect files to show metadata the same as it did with ext4 (and it does), as if files aren’t compressed. But things just don’t take up as much space.
When the working group worked through all of the options, there was a clear winner for a default filesystem that resolved long standing issues with LVM ext4, including users running out of free space on either / or /home when there was plenty of free space on the other.
There was no obvious or easy way for users to resolve that situation without a full backup, a custom reinstallation, and restore. That’s an unreasonably high burden. Pooling all the space so that / and /home share it, while still offering subvolumes as a soft separation between them so that it’s possible to reinstall Fedora while reusing /home is a significant benefit that wasn’t possible before.
OK so Btrfs definitely isn’t perfect. But if folks are having clear ext4 vs Btrfs problems, then it very well may be a bug. We need a bug report. bugzilla.redhat.com Use kernel as the component. And change the assignee to fedora-kernel-btrfs@fedoraproject.org which you don’t have to remember! You can just start typing btrfs and it will suggest only this email address. And then Fedora’s btrfs developers will see it. Thanks.