btrfs is slow too
Good Video. I always find DJ Ware’s videos very informative.
Thanks. I opened a discussion about setting the I/O scheduler on a per-file system type basis.
Well, from the DJ Ware video it seems that if you’re concerned about performance, you shouldn’t be using BtrFS. XFS seems to be a better choice unless you absolutely need a feature that is specific to BtrFS.
I wanted to dual boot and this stopped me. I fixed the problem by installing Fedora 38 with a cinnamon desktop. Now I an dual booting no problem.
I made a YouTube video of how I did it.
2 posts were split to a new topic: How do I set my avatar picture?
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
btrfs filesystem df, or
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
/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
/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 email@example.com 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
BTRFS. 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
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.
AND NO I HAD NO FIXED OPINION TO START WITH.
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.
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.
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
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.