What are BTRFS advantages over F2FS or EXT4 on Atomic Desktops?

As far as I understood, to get good system snapshots between updates on traditional Fedora, BTRFS is really helpful.

This is basically what OpenSUSE Tumbleweed does and it works well.

But rpm-ostree is way better, in that it allows to reset and keep the versioning across updates etc.

So with this quite old benchmark between the filesystems it seemed that BTRFS was pretty slow.

Meanwhile, this article reported better performance on BTRFS.

To my understanding, with rpm-ostree I am not really concerned about many fancy features for snapshotting. But maybe copy-on-write performance, are rpm-ostree updates faster on BTRFS? Or compression, used for example in Flatpaks?

Also note that many BTRFS tools like balance or defragment dont even work on the immutable partitions.

I wonder how this affects long time (like 10+ years) usage.

I may experiment with 2 VMs, one with F2FS and one with BTRFS, and test performance.

Also worth keeping an eye on optimizing SSD performance parameters


Using an NVME SSD, zstd compression on BTRFS improves the lifespan by reducing the writes to it.

Anyways, I just started to experiment with this in a VM.

I never did manual partitioning and always used Fedoras default BTRFS. But the LVM setup is also quite guided.

  1. under disk setup, chose second “custom” option (not Blivet GUI)
  2. created an LVM, default name “fedora”
  3. first partition /boot 1GB ext4 (using f2fs is not allowed here)
  4. second partition /boot/efi 600MB, default efi format
  5. third partition swap 6GB in swap format (I just assume this is wanted, even though a swapfile is also supposed to be possible?)
  6. 4th partition / without size (max) in f2fs

I didnt use encryption yet, but with this setup the Fedora IOT install (using Anaconca, cough coreOS is to complicated for me) went well and works.

My first rpm-ostree update finished well, after a reboot I can boot into the next version and now have 2 versions.

So it seems this is a very fine solution.


BTRFS creates tons of subvolumes, I didnt do anything manually.


The LVM created these subgroups:


so /boot automatically got integrated in the LVM (on BTRFS this is on a separate partition), /boot/efi is separate, and [SWAP] is automatically set to zram. Very interesting…


I prefer LVM+XFS over BTRFS. I just don’t trust BTRFS with all the troubles it’s had. If you go by the user issues here, you can see it’s a problem here and there with it.

Side tangent :

I think for new users, Snapshots is a big feature, but Fedora does not have this setup for them from the start. If it did it would solve many problems, but there is a lack of tooling there. I don’t see why they went in this direction other than RHEL might move customers to it in the future.

A proper LVM+XFS is the way to go. . .Or use ZFS.


I also dont know why Fedora doesnt automate snapper snapshots before dnf upgrades. This would prevent many issues like the recent legacy kwin issues

Because Fedora Workstation does not update via DNF by default since it uses Gnome Software + packagekitd instead? Including flatpaks, BTW. Then some day everything will change with DNF5. Maybe.

Packagekit should be possible to connect with snapper too.

But this is not relates to this thread.

It only makes sense, but I think there’s some bug somewhere in the chain from the boot process all the wayt to the desktop. I need to look back at some of my oldest post here on the forum, I think i asked this question before the move to BTRFS, and there might be issues with it.

This is also very confusing to new users, again an issue I might have brought up years ago. I don’t believe dnf5 will solve this. I see nothing in the Docs pertainng to simultaneaus update of flatpak & dnf.

I think you begin to get into the territory of containers and snaps, appimages if we go into the weeds. A new user only see’s, understands “system update” . . .

My solution is to simply have a dnf -y update; flatpak -y update command ready to go. . .

1 Like

There should be no issue hooking in a snapper backup before launching a packagekit OR dnf update.

Packagekit is an abstraction layer so yes, dnf5 will be just used as the backend but nothing changes here.

dnf does not handle system snapshots and that will not change.

4 posts were split to a new topic: Btrfs Snapshots and Backup Solutions

Sounds like the few times I tried System Restore on XP, and now I just disable it on fresh installs :stuck_out_tongue:

I feel like snapshots try to solve an issue of people not knowing how to repair their systems (aka not being familiar with the OS they’re using) or being mindful of backing up data, all the while making I/O slower.

F2FS implies performance. Fast desktops are nice :stuck_out_tongue:

ext4 is longstanding and stable, works fine on everything (desktop-ish) HDD/SSD/NVMe/USB/SD while also being fast, and not necessarily being slowed-down by the safety net Btrfs tries to be.

Redundancy is silly for performance purposes (desktop), and having both Btrfs and rpm-ostree being giant safety-nets is just that. I would think Atomics should default to ext4 or XFS (RHEL’s been doing it for years?), or do detection for auto-F2FS for NVMe.

If it’s really redundant to have both rpm-ostree and Btrfs, that also implies RHEL/Fedora isn’t entirely confident in one or the other.

I’d rather the OS handle it’s own snapshots and restores since it’s the one doing the updates and file management, vs having the filesystem do it that operates in the background of the OS. The OS has its own thing, and is hooked-up to Btrfs. Why have it hooked-up to something external and not just use your own thing?

:loudspeaker: Tell everyone ! :loudspeaker: RAID doens’t even work properly ! From last I heard, it can’t either. . .

No, snapshots also solve issues immediately occuring after an update, for the time until a fix has rolled out.

But snapshots are generally not really needed rpm-ostree, home stuff should be backed up on an external drive.

I never used btrbk but it may have advantages.

Also switching a filesystem to a bigger SSD worked (after editing the GPT table) well with redizing the BTRFS partition to max. All the subvolumes worked accordingly.

I also wonder how deeply BTRFS is integrated in the atomic setup process, as there are many subvolumes, that would all need to be replaces with partitions in an LVM.

You’re damn right about it. Failed on me the very first time I tried it. Needless to say, it’s one of the first thing I’ve disabled on a fresh Win 7 install, amongst many many others. Fun you mention it. Never installed any version of Windows above 7.

1 Like

That sounds like a distro QA issue which would explain why they want a safety net :stuck_out_tongue: , but I haven’t seen an update fail or reboot to failure yet Fedora Work/Server 20ish-40