I found some threads about Btrfs in this forum, but I didn’t see a reply to this question: what’s the advantages of Btrfs for a normal home user?
I just run Fedora to browse the internet, office usage, video streaming and so on. No need for any advanced or technical feature. Will I have some benefit upgrading to Btrfs? I guess I won’t even use the snapshots and the rollback features. I won’t need the extended filesystem on more devices and all this advanced stuff, …
Does Btrfs bring important benefits in speed, lifetime of the SSD or any other aspect that can impact my everyday use?
I know that Btrfs is far better than ext4, but I can’t understand if it brings benefits for a normal user like me
When I used TrueOS (FreeBSD) with zfs a few years ago I wondered the same things and the conclusion I came to were these 2 things:
If an update goes wrong, you can reboot into the last working version. This may not be a thing you ever have to use but for Fedora with all it’s users this could be a godsend.
You can rollback individual files, so programmers for example can go back when they need to, due to snapshots only noting differences so space use is minimal even for snapshots done every minute. I’ve heard this is really useful.
The rest of it is in server land. Performance won’t generally be better than ext4 because btrfs has an overhead in order to be able to do these things but the difference won’t be generally noticeable except in edge-cases.
Unless anyone knows different or better, that is all it is to us desktop users, but that is extremely valuable.
I’ve been using btrfs on KDE Neon Unstable and it’s not done anything funny, just works fine and rollbacks (coz you know… Unstable!) are fast and easy, and I have Fedora 33 beta on btrfs on another drive, it is set up for boot snaphots out of the box.
And just rebooting into a known working system after borked updates is one of the biggest things to happen in Linux - it’s a paradigm shift, no more chrooting!!
Thanks a lot. You are right, the reboot to a working system is important. I have to install Fedora on a new system in the next days and I was wondering if I should install it directly in Btrfs (33 Beta or 32) or keep the ext4.
Since I had some problems with Btrfs on OpenSUSE years ago (because I’m not an expert, not because Btrfs had problems) I think I’ll stay on ext4 this time. Considering the limited benefits in performance for a home user, I think I’ll stay on ext4.
Thanks a lot for your explanation. I hope this thread can be useful also for other users.
Thanks, on OpenSUSE I needed to modify the partitions and found a long list of the rollbacks (I guess) and I wasn’t able to understand how to modify the partition correctly. This is not a Btrfs problem, but it’s due to my limited knowledge.
Are you sure? When you upgrade the system (via dnf or gnome software) a btrfs snapshot will be automatically performed? And grub will support that? Sorry, but I haven’t read about this F33 feautre anywhere.
@alciregi On my fedora33 I have had 2 system updates and I have 3 snapshots in grub, the 1st one done after install.
I haven’t looked at how fedora achieve this but on Arch this is easily done by installing grub-btrfs package and using snapper from SUSE or using timeshift with timeshift-autosnap package. Either way grub-btrfs will detect these snapshots either when you run update-grub or by adding a hook into pacman and detecting them on each update. It’s quite seamless.
I only used SUSE for a short while but I didn’t like that end-users 1st use of btrfs was to use snapper commands! And the snapper-gui isn’t much better, it requires you to know stuff before it will work.
But are you sure that they are btrfs snapshots and not the last three kernels as it has always been? If you issue this command btrfs subvolume list /
do you actually see automatically created snapshots?
The first benefit to a normal user is that the automatic partitioning will create a single partition divided in / and /home subvolumes. These subvolumes will share the entire disk space. So you will not incur in the situation where / is full and /home has a lot of free space (or vice versa); having at the same time the possibility to preserve the /home in case of a system reinstallation.
In Fedora 33, the immediate benefit to the user is mainly the use of subvolumes for /home* etc, as mentioned. However, the switch also makes it much easier to introduce other features, like automatic snapshots, or automatic quotas or easy RAID or multi-disk configurations, in future releases. I’m sure that snapshots will be very high on the list, as they are incredibly useful and fairly easy to implement.
*Actually, that benefit is tremendous. I’ve been using btrfs for years, and never having to think about number of partitions or partition sizes is fantastic.
Possibly no obvious or immediate benefit for a home user.
I think any evaluation effort is much better spent on having separate, independent backups of important data, no matter what file system is in use. Btrfs integrity guarantees, and snapshots, are not anything remotely like a substitute for backups.
But let’s take the example of space utilization. Using LVM+ext4, there are separate / and /home file systems. It’s probably uncommon that home users run out of space on either. But it’s difficult to estimate. Maybe it’s somewhat common for the home user to not have a lot of storage, and maybe they share /home with other members of the household. It’s true this issue could be avoided with “one big ext4” file system. But in the uncommon case of a clean/reinstall of Fedora, Btrfs makes it easy to do that while reusing /home since it’s on a subvolume. Not common, but handy.
There are many uncommon scenarios that people run into that just aren’t predictable in advance. I expect there will be a Fedora community learning curve. But I also expect that more often than not, Btrfs will directly or indirectly, help avoid or make resolving the issue easier. Btrfs isn’t perfect. There are tradeoffs.
Also, note that LVM+ext4 will continue to be release blocking storage technology for the foreseeable future. It’s reasonable to have a subjective preference for the familiar, to continue on that course, and evaluate Btrfs by observation for a little while longer.
In my case, I’m using Btrfs everywhere. Laptops, the server, the Raspberry Pi, and all backups. I do trust it.
Snapshots are simply the minimal way to point to data. So all the possible iterations of data blocks are stored on the drive but the snapshots are simply pointers to each time they are taken.
In practice this means that if you only add data, the addition of snapshots is next to nothing, no matter how many snapshots you take because they are only pointers.
But if you remove data, it has to keep what was, and what now is, in order to load the data from what was or from what now is.
So it effectively has to keep each relevant individual block of data in order to recreate each snapshot in time that is recorded.
There is no copying of data, only keeping what is needed to recreate a snapshot record.
Btrfs tools allow you to manually create a snapshot and also delete a snapshot. If you use SUSE snapper you set up a repeating event and tell it how many to keep. On KDE Neon I use a tool to take a snapshot before every update and I use a command to remove every snapshot older than 2 days when I see fit (or remember).
And there are additional tools to create a full copy of a snapshot so the snapshot copy actually contains all the data, just like a backup. This is set up with btrfs send and receive commands and casn be used to make full backups on different drives or machines.