btrfs-assistant is already in the Fedora repositories, it helps you manage subvolumes, snapshots (timeshift and snapper) and also BTRFS maintenance tasks (balance, scrub). Can’t get easier, I have been using it for over a year.
1 Like
@rkoppelh , thank you for your remarks. these are valid.
that approves my subliminal bad feelings (too complex, not mature…) i always have when/since using btrfs.
for example, i just managed to completely hose up a fresh linux mint installation by activating compression and using snapshots, resulting in an obscure and unresolvable grub boot error.
furthermore, i have seen issues when using btrfs with proxmox. proxmox is adding hidden/silent quirks to their hypervisor/qemu that it works with btrfs, and as we see - quirks are … just quirks
https://bugzilla.proxmox.com/show_bug.cgi?id=5320#c2
if you don’t have those - you’re getting into trouble:
https://bugzilla.redhat.com/show_bug.cgi?id=1914433
people even blaming qemu/qcow for that
furthermore - recently O_DIRECT has been added to zfs - and they seem to have done it thoroughly and done right.
btrfs has NOT:
https://bugzilla.kernel.org/show_bug.cgi?id=219783
i am using ZFS a LOT and it is a mature and stable filesystem and it’s a pleasure to use. i love it.
i wished btrfs had grown more mature and usable over the years, but i guess we probably won’t become friends in the near future…
i think btrfs is quite cool, but sorry to say - it’s not mature and the learning curve is really high. it’s utterly complicated and ZFS is A LOT more easier, comfortable and mature.
That would be a problem with Grub. There are other boot loaders that can be used.
More context needed? What was the partition layout? It could be that you restored an image with a nonexistent kernel in /boot
I have BTRFS with encrypted root and compression, working solidly well. And I have VMs on the BTRFS filesystem in a separate subvolume with nodatacow flag on the directory.
I agree ZFS is more mature, but BTRFS is solid enough for the average user.
1 Like
I am also running everything on BTRFS now with compression, and I am never looking back. Even my /boot is BTRFS now. 
Nothing better than incremental backups, dedups, compression, online resize, etc. in a native linux way.
The only problem I ran in the beginning was running out of space on a BTRFS partition, which is not handled well. You basically have to watch your space usage, balance if needed.
Btrfs maintenance script could help automate this for you.
Absofreakinglutely. But it was a surprise/confusion in the very beginning.
Errgh ever ran out of partition space re ext4? No diff but diff in technique.
Fascinating how this thread has grown. My technical decision, I use ext4 for ‘/’ to avoid btrfs risks, xfs for partisions needing high performance, btrfs for /home and other such partitions and and I would use zfs for raid type system of multiple disk. That’s the roadmap of disk formats I now use. Each has their own pro & cons suited for a particular purpose. But for /, basically your core OS & kernel you want performance, reliabiity and ease of use with well proven tools. If it cags itself you reload it but it should not have sensitive/critical data. dataB. TRFS when I last used it does not tick the bill for ‘/’. But i expect it will get there but remeber it is technically more complex which always comes with the penalty of speed.
What risks?? BTRFS is 100% stable.
No, you just back everything up, as you should for anything anyway, and it’s 100% safe for sensitive/critical data.
What complex? What speed? Look at benchmarks. Use SSD and NVMe SSD, if you really care about speed, do not trade off incredible filesystem with amazing features that performs with amazing specifications.
is it?
I ran scrub and it wiped my entire GPT data from a SSD.
Nou running ZFS and I am happy, really happy.
Performance and stability is way better!
Did you report this problem?
Was it investigated?
Was hardware issues ruled out?
1 Like
The answer is NO to all your questions, I was in a hurry so didnt have the time to report. I was needed my station to be running.
The SSD is 1 year old, no issues at all, since then it is running like a horse.
PS happened to me twice (reinstalled fedora 41 twice, both times with btrfs), third time I gave up and moved to zfs.
BTRFS operates within boundaries of a partition defined by GPT. BTRFS does not know about anything outside of a partition defined by GPT. Therefore, it cannot manage or access the GPT regions unless specifically instructed by the user to overwrite the raw disk outside its designated partition by mistake.
no idea, I only ran scrub and after a restart GRUB was gone with the only option to boot from IPX.
started to investigate and loaded gparted from live usb to see what is going on and it said GPT is missing.
twice, the same action
What risks?? BTRFS is 100% stable.
That’s a big call 100%. Further no I have had weird things happening with BTRFS. See my original start of thread.
This is the reality published by the developers themselves:
Even developer data suggest it is NOT 100% stable.
Pls do not denigrate people who’s experience and opinion are different to your almighty church altar perspective.
Timeshift was my / backup from btrfs volume to a btrfs volume. That did not go well like described in start of thread. When / became ext4 everything works including bups onto a btrfs volume. This may not have been a BTRFS problem but a timeshift app problem. But that’s also an issue for users. Compatibility with some system mgt apps! Common linux tools read a different disk usage to what btrfs tools provide. Maybe that’s fixed now.
I do find it curious how stingingly defensive BTRFS advocates get on ANY criticism. Like it’s heresy.
There is a performance difference even on SSD when I researched it (including benchmarks at the time) of a few % ext4 and btrfs. It also makes sense because btrfs does a lot more vs ext4. See as an example (and plenty more elsewhere):
btrfs-vs-ext4
As mentioned early re file formats its horses for courses and my mind map of usage of formats for particular use case is MY mind map of how I look at it. I am not saying BTRFS is bad, it’s just young, it has pros and cons like everything else and therefore is suited best for certain applications. In my experience not so much re / os files but good for /home /srv /mnt. It’s my opinion and it now has served me well. Hence I do not listen to the preachers from upon high.
1 Like
No software is bug free, that is as true for btrfs as ext4 as zfs.
Small numbers of reports of problems need to be balanced against a large number of working systems. And we have seen active involvement of btfrs maintainer on this forum when reports are made of issues to investigate and resolve them.
In the case of one problem above it was not reported or investigated.
If you look at the issues listed as not Ok, they will not impact most systems.
1 Like
No software is bug free, that is as true for btrfs as ext4 as zfs.
Be that as it may, in the nearly nearly 30 years I’ve been mucking with
this “Linux” thing, supposedly ‘stable’ btrfs is the only one that’s
managed to completely eat itself across a clean reboot cycle. Twice.
The first time it was so badly wedged that the recovery tool segfaulted.
Two weeks after the reinstall, it wedged itself again, but while the
tool was able to make it mountable, it was so trashed that it was
effectively a total loss. No fancy features like raid, subvolumes, or
even snapshots. Just a plain-jane root filesystem on a
very-lightly-used HPTC.
On the next reinstall of that system, I went back to tried-and-true
ext4 and that hardware remained in service without so much as a hiccup
for the next eleven years, most of which was under much harsher
service than that initial btrfs experiment.
I’ll freely admit my experience is quite out of date now, but you can
understand how damning of an experience this turned out to be. After
all, if supposedly ready-for-production btrfs couldn’t even reliably
survive a clean reboot cycle, how could I ever entrust it with anything
that actually mattered?
Small numbers of reports of problems need to be balanced against a
large number of working systems.
As the saying goes, where there’s smoke, there’s fire. Which needed to
be balanced against the conspicuous lack of simimlar reports of other
filesystems completly wedging themselves under normal usage patterns.
- Solomon
Everything on that status page says OK.
You will literally see no performance difference overall, the overhead is just so minuscule for any average user. In fact, you will see performance enhancement when you account for all the perks that BTRFS provides to you (that no benchmark will ever account for in entirety). Which is not just because of some extreme use cases.
I do feel there can be a better way to deal with running out of space on a BTRFS partition other than actively manage your partition.
Yeah, super out of date, so unclear why you’d even feel this is appropriate to word your post like this.
We are talking about a pretty mature filesystem here.