On my initial research considered zfs vs btrfs. Same conclusion zfs even more involved then btrfs. Concluded zfs for large complex multidisk storage arrays, i.e. data centre. Not worth my time. Hence I gave btrfs a try.
If I was using raid then I would definitely go btrfs over mdadm & LVM. Btrfs then would win hands down due to checksum, self-healing etc.
But as the main rootfs or where you want performance and redundancy/reliability is secondary then I will stick to ext4 or xfs. That’s my conclusion anyway.
You should always have multiple copies of important data. RAID is good for increasing uptime (and for convenience), but is not sufficient. You really should have backups. In that case, a btrfs error tells you when you need those — or, when there’s a problem with the backup itself.
That was the plan. But the external ‘rugged’ hdd I chose from ADATA appears flawed. It can’t handle a stream of data beyond 300 GB (Capacity 1.8TB) and then seems to throttle from normal usb3 speed to < 100 kB/sec making it completely useless. So need to wait for a replacement. I suspect it’s inherent in the design.
Be wary of ADATA and it’s claims re it’s ‘rugged’ disks! They are cheap - for a reason?
Oooh thank you for that didn’t know there are different flavours of them now. That certainly could explain it ,but manf never mentioned it and gave me an RMA numbers to return it when I complained. Spec sheets didn’t mention this either.
Per wiki article a controversy as manufacture do not advertise it. Not a problem here in Oz as the drive needs to be ‘fit for purpose’ as a slow time to record makes backing up of man 100s to 1000 GB impossible.
I have one of those nasty drives as a secondary drive in my laptop. After relatively large data transfers even when disk activity LED stops and the disk is idle, I can still hear its actuator moving around exploiting the idle time to flush its buffers or whatever. Definitely will watch out to get a CMR for my future NAS.
I’ve been using btrfs for as long as it has been default without any perceived issues, but decided to go back to LVM + XFS for Fedora 38 to align the system closer to RHEL. Interesting I may have stumbled on a good choice.
One thing that started working notably better for me was GNOME Web. When I tried GNOME Web 44 on my F37 SB with btrfs it would frequently timeout when loading pages. As soon as I upgraded to F38 and made the filesystem switch it started working perfectly.
To be fair, I didn’t go back and completely isolate the issue, it may not be that at all, but I am certain GNOME Web was practically “unusable” before and then it was perfectly usable. It was a flatpak and the version didn’t change between installs.
I don’t know where I surfed across it on the web, maybe toms hardware but article comparing btrfs performance recently to xfs, ext4 and btrfs was slower then all the other. Measures on latency where particularly subpar compared to the others. Since my system uses ext4/ XFS on rootfs I can not make a comment on the issue you highlight but btrfs is known to be slower in other comments and on roofs it may slow things like you observe down but a complete time out as you observe is doubtful but I don’t know.
Your experience if other have it as well would suggest a controlled comparison test needed comparing linux roofs performance vs other fs in real world apps. Surely that’s been done somewhere before a decision was made to make it the default rootfs???
BUt subjectively your observations of faster performance of roofs re web pages when using xfs + LVM could make sense. Also definitely different behaviour by other apps when working with btrfs as I noted re timeshift. Interface with older apps, i.e. regression MAY not be 100% and so occasional gremlins will show up.
A classic developer issue of our interface is more modern then the old, we’ll make it work but change to our cause it’s better. In other words let’s fix something that wasn’t broken and guess what happens per Linux Torvalds critique, you break linux.
FS are the cogs of linux. Be careful changing the meshing of the cogs or the friction of the OS increases, that would be my analogy.
Modern features are not the only measures that should be used in adopting default FS’s. It’s how well they work with the admin tools and general operation and use. To avoid friction extensive regression testing should have been done. I don’t know the answer to that but my minimal experience and observations to date raises ‘???’. Your performance observations adds another small log to a small wet smoky fire. It confirms my decision to be conservative and not use btrfs for the rootfs (i.e. default) for a little while yet.
The implication, those who want performance, stick to ext4. Those with multidisk roofts and who want reliability, fill your boots with btrfs but maybe expect a few odd things happening with apps.
I went back and tried to reproduce the issue in Boxes and to be honest I couldn’t. It was far-fetched to begin with… even though Web didn’t change between installs the entire base OS did. So I apologize for even bringing that up.
Again, I didn’t necessarily have any issues with btrfs. But I was reading why Red Hat dropped it and what the latest was on whether they were ever going to bring it back, it just doesn’t seem like it is even a thought right now. There was one particular Reddit post where a lead engineer basically said Red Hat has made a bet they can implement most of the features of btrfs with less bugs and vulnerabilities. Also it goes against the Unix philosophy as it is trying to pack a bunch of features into one solution (to be fair, so does systemd and it has proven invaluable).
The technical reasons given at the time for going btrfs by default definitely made sense. For me personally, I wanted to align my system a little more with Red Hat’s philosophy as I believe in them as stewards of software and want to help their cause moreso than Facebook, Oracle, etc. Ultimately though I am glad Fedora is working on btrfs and that people have options.
Interesting what you say re unix philosophy. RH is right and aligns with what I think re dabbling experience with btrfs re my backup drive.
The BTRFS cogs (analogy of mine) are not quiet right. This is causing potential ‘meshing problems’. RH would know more re the bugs, but I’ve seen hints of them re my timeshift experience.
This again aligns with what I believe is that btrfs, since it is per your statement not aligning with unix philosphy (i.e great new features but with complexity and different or new FS management interface), basically code for don’t fix something that ain’t broke or you break it or add interface friction.
I also see RH (IBM) sense that ext4 with LVM can incorporate many of the btrfs features. Evolution re the cogs, not revolution. So I would certainly support ext5 with LVM 3.0 improvements incorporating the features of btrfs better checksums, self healing re any raid/redundancy, ease of raid inline management without unmounting.
Re the old chestnut argument that btrfs is better on dealing with disk full situation then raises the question why did your disk get full without realising it before it’s too late? It usually means you don’t monitor your disks (I use system monitoring widget on my desktop and I always know the state of my disks, temperature etc. That btrfs argument is kind of like saying drive without monitoring dials, leave it up to Tesla to auto drive and expect nothing will happen and it will fix itself in utopia as AI knows all.
Those sort of statements come from people who haven’t experienced REAL live yet and spent far to much time behind a computer screen.
Interesting, I like the concept. EVOLUTION - I like. Thanks for the link. May consider trialling it in a virtual environment.
Curious about how the extra layers of stratis impact the performance of the existing ‘lower layers’, i.e. how is the performance of XFS impacted would be interesting?
Will they do this re ext4?
Big move forward if after the pools setups and encryption, the normal fs management commands work as normal. Then all existing apps and scripts out there will be happy and regression is addressed.
Website description did not mention any self-healing?
ext4 has lots of issues that that make evolution very hard apparently.
What zfs and btrsfs have in common is the understanding that the layering
that was done is a barrier to features and performance. They both break
the layering . This allows for smart error handling as low level issue can impact high level robusthess for example.
This is from what I have read.
It will be interesting to see how stratis achieve this.
Yep, another issue I’ve faced is that my system says my home partition has 60GB available, but when I try to use it downloading, copying or creating files always fails. Is that 60GB available or not BTRFS? make up your mind.
Switched everything to BTRFS last year and never looking back to ext4.
BTRFS is hands down a million times better than ext4 in every way. It just requires a little management. The learning curve is a little steep but extremely low - you only need 5-6 btrfs commands to do anything you should/want to do with it.
There’s nothing better than the ease of the incremental external backups with BTRFS now. Great compression. Great subvolume/partition handling. Deduping large backups. It’s the most incredible stuff.
Even my /boot partition is btrfs now. I think even my BIOS is BTRFS now too.
If it requires learning why is it default? Also why would it not let me use a bunch of my storage space on my home partition that’s supposedly free? I honestly can’t fathom why fedora uses these new and unstable tech like that and zram. From my usage they’re just slower, less efficient, and over-complicated.
btrfs balance start /home literally gives a warning not use it, then what is supposed to be used?
I mean it requires learning to use ext4 too. It was only after some years I learned that formatting ext4 with -m 0 frees up 1% or whatever of free space.
In the case of BTRFS it’s learning that allows you to manage it and do things that were just not possible with ext4.
You can google how to properly rebalance your BTRFS if needed and just save the entire 5 commands you need to ever use in script files so you don’t need to type it - and add a cron job if needed for maintenance to never do it manually.