BTRFS - I surrender! Good features BUT Complex, wastes time, not KISS, does not play well

I saw that video and tried different scheduler. Didn’t make much difference on my install but my rootfs is ext4 but my internal backup ssd uses btrfs which is acted on by borg.

Performance wise changing scheduler didn’t make much of a difference when using using crystal disk or similar.

Note what prompeted this discussion is issues with my backup btrfs disk. Turns out once I used a normal hdd ext4 being written to my btrfs issues went away. I haven’t looked into it further but I noted somewhere else that timeshift may not play well with btrfs.

Anyways I’ve kept the btrfs bup disk but resolved for other future work to stick with tried and true ext4 of xfs.

btrfs is not prime time was my conclusion. I have plenty of other issues without adding to them with a new file system.

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. Use kernel as the component. And change the assignee to 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.


While I understand what your saying and the need for a bug report, I like many other people in the world, suffer from time deficit disorder. Even writing to you takes up precious time.

I’ve done bug reports re Centos issues in the past. Each one resulted in hours of back and forth. I was happy to do that as I needed problem fixed and there was no alternative solution.

In this case I had a choice. Start a bug report and spend time with the ping pong of back and forth, test this or that, or use ext4, XFS and LVM that I know well and can setup a new working partition configurations in a few minutes and move on or spending hours (which I did) getting my head wrapped around BTRFS for which std linux file management commands ‘mostly’ work but as you say sometimes they don’t.

Further I use (maybe like timeshift) std bash linux system calls in my automation scripts (like for borg backups). So I rely on df, du, ls, lsblk, fdisk etc. Sadly btrfs adds ‘btrfs fi xxxxso-on’ for disk space interogration meaning backward compatibility issues and possible re-write of automation scripts.

Now I use timeshift that I came across re much recommendation on line years. Easy to use - it works. Under a minute of click click click done! Reliable! I used it in Rsync mode as only my backup disk is btrfs, everything else was ext4 or XFS. The btrfs backup multi-disk arrangement, of different disk sizes in single mode was for me a trial of btrfs. Both timeshift and borg write to it. But timeshift reports (maybe due to different sizes of the combined btrfs) as reported in my initial post at top different disk usage depending on which tab and then reports disk full when inspecting sources and other tabs while other bash tools see no issue re disk space.

Easiest solution for me was to try timeshift on a std ext4 hdd. I knew it would work. Problem for me was solved. Borg is quiet happy with btrfs multi-disk arrangement. That’s about as much debugging time I had.

So yes I understand your frustration with me. But from what I could see there’s much hype re BTRFS and the rational decision for making it default. Hype that my experience above did not support and so I wrote a warning to others with similar time deficit disorder. So I apologise but I also stand by what I said.

I also need to say I moved from centos 7 to F36, now F38 due to IBMs decision. I liked centos, v. reliable workstation. Best ever OS for such use.

F38 is good, but I prefer reliability of centos but the choice was taken away from me.

In this case I had a choice. Start a bug report and spend time with
the ping pong of back and forth, test this or that, or use ext4, XFS
and LVM that I know well

In the time you, and others, spend on this discussion, you could have
very well opened a bug and took the discussion there.

Since you had already made up your mind, it seems, in what filesystem to
use, this feels more like I need to let the world know what I think of
. While everyone is entitled to give an opinion, it strikes me as
conflicting with your described time deficit disorder.

I also need to say I moved from centos 7 to F36, now F38 due to IBMs
decision. I liked centos, v. reliable workstation. Best ever OS for
such use.

F38 is good, but I prefer reliability of centos but the choice was
taken away from me.

I’m not quite sure I follow. There’s CentOS Stream:

Yep and here are the trolls.

I tried it - it looked good and has promise. I am not opposed to btrfs. But in my use case I am moving on. I only highlighted that there is some hype re btrfs.

I did a lot of research post centos 7 (& time) to choose my next best distribution. Rocky was also considered with Ubuntu, Debian (learning curve). Given Centos familiarity and Stream being only marginally better to me Fedora was best choice. It has except me brief foray into BTRFS.


I used ext4 & XFS for F36 as there where issues of concern re BTRFS a few years ago. For my F38 upgrade and need for disk replacements decided to give btrfs a try. That try did not work out for ME! Because of they try I saw flaws in the hype of the promoters. So do others above.

Now I get attacked for a conservative opinion. The problem that btrfs has is it has competitors in ext4 and XFS and TIME.

Re bug report. Yes first one is easy but then you get sucked into try this, collect this and as one gets dragged into the debugging process.

Fine for some not fine for me as I have other things to do besides IT, like keep a wife happy, mow the lawn, fix the fences, repair the car, do the taxes (for which I need my IT), research, code other things for which filesystems are unimportant and so. Time and money!

So how about you accept my view as just that rather then be an attacking troll.

1 Like

Let’s keep the conversation respectful. Just because someone has a different opinion doesn’t make them a troll.


If you want a conservative distro, you know where to find it.

Screenshot from 2023-05-24 13-00-00

Fortran on punched cards and then Pascal on VT100 with Vax machine was my introduction to Computer science.

Why do older people get conservative?
1/ Time - you have less off as you get older,
2/ Over the decades I learned something that’s not in a book or lecture
i) KISS,
ii) Don’t fix something that ain’t broke, and
iii) Don’t reinvent the bloody wheel!

Still wreken for the whipper snappers that punched cards are the way to go. The programs execute so much better with real depth while the remaining chads, the smell, the memories …!

Sorry about the troll comment. My only defence - I didn’t start the attacking for an opinion.

Actually, and not to argue here but just a factual point since I feel deeply about proper communication, the KISS principal as it was introduced to me by someone much more intelligent than I, was “Keep It Simple because I’m Stupid”. They were my boos, and were in a hurry at the time, so I kept it ‘simple’ in that instance.
As for BTRFS, I think from my experiences and what I have read about file systems such as XFS, is that it is far more robust to handle the modern disks errors, which are not “failing because they’re broken” like the older devices do. XFS doesn’t seem to have as good a grasp on the recovery from errors or a good error handling strategy as far as I have read awhile back from a white paper published out of the U of Wisconsin Computer Science Department, in which they give their results of testing it for failure recovery and error detection.

That’s why I wanted to move to BTRFS backup disks. I was coming of a raid10 system with standard external timeshift & borg backup. All the disks worn out at 50,000 hrs ea. Replaced with single nvme ssd only as the reliability from my research was at least equivalent. Other then for performance, ssd makes raid redundant in my case. For back up had 3 SATA SSDs, one 1TB and two 250 GB. Bups are around 700 GB. So ran them in single mode. So that’s why I considered BTRFS as a try vs. LVM. Further liked the BTRFS checksum options and inherent compression to squeeze it in which should give some reliability. Borg works great on this. But as mentioned timeshift when you move to the gui tabs sees the BTRFS as full when it’s not. But the biggest issue is the need to rewrite my automation scripts due to the different BTRFS fs management command structure. That’s probably the timeshift problem in it’s scripts. Wasn’t willing to go there time wise to rework all my scripts. KISS was timeshift onto a HDD I had spare and borg on the BTRFS which for me is the trial of the fs maybe for future adoption on a new computer as btrfs improves - performance and compatibility being the issues as I see them with now a little experience.

But I also agree for the BTRFS developer consider a KISS for the rest of the Linux community. If you look at ‘man btrfs’ it becomes a case of a ‘smack in the face’ rather then a KISS.

KISS is about being simple for the problem you are solving.
Its is not an absolute. Is btrfs move complex then needed to
solve its requirements?

why do you think RAID does not matter with SSD?
The point of RAID 10 is to survive a drive failure.
SSDs can and do fail.

Your example of all drives failing at the 50k hours point is too small
a sample to be meaningful. The annualised failure rate is typically 1% to 2%
which means you need a few 100 drives to see failures reliably.

I would first state that I respect your opinion to prefer or use a different filesystem and I would acknowledge that btrfs isn’t the best choice for every use case.

I would say that after reading through everything it looks to me like the majority of your issues are self-inflicted. Btrfs in Fedora is deployed in a fairly simple way by default. It doesn’t require any advanced knowledge or special skills to use.

However, if you have the time and willingness to learn about it, it has many advanced features that other filesystems don’t have. Of course, you don’t need to use or learn about them and can generally use it as a simple filesystem. I suspect that many Fedora users don’t even know or care that they are using btrfs.

On top of that, the current state of timeshift is fairly terrible. It has been on life support for a while now and has many issues. The good news is that there is recent work by new maintainers so hopefully it will progress. That being said, I know many people using Timeshift with btrfs without any issues.

To be clear, I am not trying to convince you to use it. If you prefer a different filesystem you should use what you like. I just think that some of the statements in this topic are a little over the top and wanted to share my perspective.

Never said raid doesn’t matter. Why do you think I am doing backups anyway? Of course SSDs fail doooh!

But when you look at the data SSD in normal use are more reliable until they reach an age of around 5 years (it’s not just writes, the semiconductor ages), but compared to 4 or 5 hdds raid I used to use, the cost and electricity, ssd with single backup ssd is cheaper and should be as reliable.

BTRFS did interest me re it’s better checksums to compensate for no raid. But alas didn’t work out.

Re timeshift - works perfectly with supper KISS on HDD. Didn’t on BTRFS in same configuration.

People stop judging me. I have been an engineer for 40 years. Grew up from punched cards and PDP11 & VAXs to High Performance computing including F18 flight simulators, electronic warfare, media rendering and editing, scientific computing and simulation, a scientific UV telescope flown aboard the space shuttle etc. I even invented & build a 2GHz computer in 1994 using GaAs bit slice technology from Vittesse for Electron Pulse resonance system for an University. At the time fastest PC chips ran at 60 - 100 MHz.

After 40 years of experience and many fashions or computer fads I’ve seen a lot. Eg cloud computing a disguise of central computing of the 70s era with dumb terminals hanging of rs-232 lines replaced by internet and rj-45 plugging into now pretty downgraded PCs with much of the smarts centrally located and charging 10x more when you capitalise the annual cost while the central computer operators (sorry data centres) have you by the balls eg Google, Meta, Amazon, MS etc. The whole point of distributed computing in the 90s with the invention of the PC was to get away from that central control and reduce cost for consumer and small business. Gone full circle. Now for those wanting jump down my throat on that OBSERVATION & OPINION, it is not an attack or critique of current technology it is an observation that can see through the hype based on decades of experience.

Anyways I divert.
Re BTRFS, My opinion which I still stand by, my experience, my solutions for my use cases.

Doesn’t BTRFS require a RAID for checksums to be useful in error recovery? Otherwise it just detects errors.

I agree, it screwed my system multiple times last year on rsync+ext4 backups (I think it messed with SELinux), now using snapper+BTRFS for almost 1 year without issues.

No worries, no judging here. As for my reasons that made me want Fedora to use BTRFS as default … even the author of ext4 was saying it was time to use something more modern … a modern Copy on Write filesystem … open source … ease of resizing (actually, not even a problem I consider anymore) … snapshots!

Yes, of course.

I’m not sure, but detection is the most important part. btrfs prevents you from reading corrupted data, so bitrot caused by storage failure is impossible. That is the single most important feature of btrfs IMO.

That’s what interested me re BTRFS - bitrot detection. I know about the raid re checksum and the inherent repair. But I had limited budget and disks of different sizes with 2 being Samsung 830s. So for BUPs I wanted better checksum. After all SSD age has a big influence on errors. Those older SSDs have not been written much.

So btrfs appealed to me a few months ago. I was open minded. I wanted to give it a go. It’s the practice and time that turned me off. I just want a backup disk running borg and timeshift not an entire lecture course on btrfs that I had to go through to join the 3 disks, manage them, integrate crypto and this list goes on to integrate it as a working system and then timeshift didn’t like it. That were btrfs lost me. BUt I’ve kept it for the borg bups.

Note Initially considered ZFS and compared BTRFS. There it seemed that BTRFS had lower learning curve and ZFS was over the top for me. Definitly aimed at RAIDs. Great for Data centre not so great for small network and professional workstation and some home computers.

Note also re your comments the default Fedora comes with BTRFS default. My initial install was 2 years ago with F36. BTRFS not there then from reading at the time. Besides I was coming of Centos 7. Centos people are conservative. So did install with ext4 and XFS for folders holding larger files like multimedia.

Also I do scientific and media computing. Need top end processing performance. BTRFS is slower then ext4 & XFS re performance. So BTRFS best suits me for backups storage where that performance is less important. Just store it reliably and tell me if there’s a problem.

Linux or Unix is used often used in high end peformance computing often limited by I/O throtteling (media rendering). BTRFS is an anathema to that from what I’ve learned. Not a critique just XFS is better for that.

Re more modern file system then ext4. I don’t disagree. But modern does not mean more complex or not backwards compatible that older programs such as timeshift or many developed custom scripts fail. A change in filesystem should not force the users to change all their apps. Eg. Colour television introduction ensured that they could still deal with monochrome and other older communication standards of the time. It takes time to transition. Don’t force a time line on the user because as a developer you want to move forward without regard for any one else. As Linus Torvald said (or something like it), don’t break the OS with your upgrades. The fact that Timeshift does not work on BTRFS as it’s backup yet ext4 or others means the btrfs file management interface is breaking some apps.

A fs should never do that. BTRFS commands should work seamlessly with ls du df fdisk gparted lsblk and all the others and provide the same and correct information without having to resort to btrfs fi … etc. Then the interface with older apps gets broken. That’s what creates the complexity and makes a mess of KISS.

I think zfs can be a good fit here too. I certainly use it this way.

However, zfs has a significant learning curve. Much higher than btrfs. zfs is not at all the right choice unless you are willing to spend time learning and planning your filesystem up front. It definitely isn’t for everyone.