The ratio of bad to good posts has always stunned me too. But for the opposite reason.

The linked post explains that there is a performance regression in a very rare and specific usecase: creating 100k files in a short span of time. And I'm not talking about unpacking boost, that's not enough files.

Additionally, it will be fixed before any distro packages it. (even Arch is still on 5.9.14.)

On the other hand btrfs got rather impressive speedups for fsync https://www.phoronix.com/scan.php?page=news_item&px=Linux-5....

Why are people making so much noise instead of just reporting the bug upstream when stuff goes wrong with btrfs, and why do we hear so little about the positive impact of new improvements. Almost like the people behave like customers of commercial operating systems. :-)

>creating 100k files in a short span of time. And I'm not talking about unpacking boost, that's not enough files.

In JavaScript world that's really not that much. A project I've been working on has 120k+ files in node_modules, and `yarn install` creates the whole directory tree in a few seconds. It's not some obscure issue nobody ever runs into.

this is fair and i will cop to most of my exp in linux being in the "mainstream"/"commercial" filesystems. guilty as charged :)

Not btrfs and anecdotal but fedora 33 / 5.8 kernel / default gnome was unusable for me on amd r5 3500U. Headphone microphone didn’t work. Bluetooth ear phones and mic didn’t work. USB headphone microphone worked though. Sure enough most of the issues were resolved by 5.9 but I can no longer recommend Linux on the desktop.

With the problems you are listing, you would have never been able to recommend Linux. The problem stem from lack of driver support in the kernel for the devices on your machine.

If that is the case, then your machine maker obviously does not support linux. So, it's no surprise that your machine had problems with linux.

If you buy a machine that supports linux, you would not see those problems. Nothing to do with linux, mostly to do with interaction of linux and your machine manufacturer.

Sorry I failed to mention that things were much better before the update. Sure the fingerprint reader goodix never worked but the things I mentioned above are regressions. I’m all in favor of wayland but if we say we remove existing working features (fedora 32) because security or whatever we might as well wear tin foil hats and stay away from computers.

I suggest you try Ubuntu LTS (not latest) or Debian less coolness factor but you don't get regression because only security updates are happening. Your hardware must be compatible and you need to resist the urge to get the latest shiny stuff.

Over the last 15 years, I've run a lot of distros on a lot of different hardware.

On desktop, Fedora has been by far the most reliable. Ubuntu LTS, as far as I can tell from using it for work, just means that annoying bugs that have been fixed in the upstream never get backported.

Case in point: Bluetooth on Ubuntu LTS has always been much less reliable for me than on Fedora.

Disclaimer: This is only my anecdotal experience, use whatever works best for you.

You can't have it both ways, you can't get only the bug fixes without the new bugs , except on LTS you can if you know how experiment with getting a new kernel or video driver but not updating your DE,

> getting a new kernel

> you can't get only the bug fixes without the new bugs

> if you know how experiment with getting a new kernel or video driver

I would agree with you if I was on my old machine with an nVidia graphics card which for what it is worth my new machine is a much better experience with AMD processor and integrated graphics but still how do you explain audio in failing to work as soon as I upgraded to Fedora 33 / kernel 5.8 and it (mostly) resolving itself when upgrading to 5.9 kernel? Is this a kernel bug or not? What caused it? What can we do to prevent it from happening in the future?

What I would personally do is install Kubuntu LTS, then if I really need a new kernel because some hardware feature I enable a PPA that gives me that new kernel , if I need a different NVIDIA driver I install a PPA and try all the availleble drivers, find the one that works. Then if all works fine I don't upgrade the kernel or driver until I am forced and I always have the option to rollback,

Then when I want to try the next LTS years later I install it on a different partition and check if it works or not for my use case.

For my work I use Intellij , when there is a big update I get the .tag.gz and try it. If something goes wrong I still have the working version and I can go back.

Updating to latest and greatest was fun when I had the time and when I knew how to format the disk using "fdisk" and it was pleasurable to read and tweak stuff, this days I don't care about shiny stuff and my work does not require latest libraries and I am not using any first gen of hardware.

So IMO if you want stability and no surprises and the ability to maybe upgrade the kernel and a driver Ubuntu is a good solution(not sure about Debian or SUSE) and also I don't have experience with Wayland so maybe that invalidates things and is impossible to get a stable working Wayland setup.

It's not as compelling to write about positive experiences.

The main competitor to btrfs is zfs, which is harder to set up, arguably more complex and has licensing issues so you can't really ship things with it built in.

I like zfs on my server, but am also happy with btrfs on my laptop.

ZFS is not harder to set up imo. It's as easy as `sudo apt install zfsutils-linux` and `zpool create poolname raidz2 disk1 disk2 disk3`

I've been bitten by btrfs back when it was the new hot FS, so I'll just stick to ZFS until a distributed (multiple machines) equivalent of ZFS comes along.

> until a distributed (multiple machines) equivalent of ZFS comes along.

Ceph?

That's exactly what they want. It's got all the checksummed replication features that makes zfs awesome and it's pretty rock solid. It's even pretty resilient to dumb mistakes from the admin (ahem). Unfortunately ceph is primarily developed for folks running massive petabyte scale clusters, so setting up a home lab micro-cluster is still a fair bit more difficult than it needs to be, even with the new cephadm stuff. To wit, figuring out what the best practices for setting things up to run a small scale cluster is often guesswork and the pitfalls aren't always obvious.

I work (well, until January) for a company that specializes in Ceph support. And it is depressing to see how many customers have crashing OSDs or MDSs, or unexplainabe memory overuse problems. It looks much worse than btrfs. I don't want this at home. But, to be fair, for every distributed storage system (even as simple as DRBD), there is be a person who had extremely negative experience with it.

Synology has been using BTRFS for a while, I haven't had any issues with it.

https://www.synology.com/en-global/dsm/Btrfs

It's interesting to compare with QNAP, a competitor of Synology, that does not use Btrfs (they stick to ext4 with mdadm) and they explained why: https://www.qnap.com/solution/qnap-ext4/en/

However, I am really not sure if the facts they provide are still relevant today. Like always with commercial documents, that must be taken with a grain of salt.

They use it just as a filesystem, like ext4. The RAID is still the classic Linux RAID because btrfs RAID isn't stable.

This means BTRFS isn't able to heal itself because there is no copy of the data that BTRFS could use.

I built my own NAS so I can just use ZFS with raidz, and when I ever have a silent data corruption the repair is done in a few seconds, not hours.

Unfortunately not available on every model.

Nobody posts about things that are working fine.

Does OpenZFS have a similar ratio of bad to good posts?

ZFS's killer feature is religious inspiration.

Write holes during resilvers are healthy and natural, but the same in a software RAID 5/6 configuration on BTRFS is unacceptably risky.

Brought to you by the same people who don't think SMR disks are used with ZFS in enterprise.

Forgive me but I'm completely missing what you're saying here. Are you saying that ZFS has a write hole when reslivering?

Raid5 on btrfs is not and has not been production ready. It's available in the code, but with appropriate warnings. You're not supposed to be using it, rather than it being "unacceptably risky".

That's the problem with btrfs. Raid5/6 still isn't production ready and loses data with cheap consumer ssd which could to disappear/reappear in a running system. On the other side raidz/z2 works rock solid. Of course I could use btrfs with mirrors instead but that's the reason why I use cheap consumer ssds. I can't spend that much money just to use btrfs so I stay with zfs.

It doesn't, but also their changelogs aren't seen by people who browse Linux changelogs. You'd look at https://github.com/openzfs/zfs/releases (which also contains a few bug fixes) if you're interested in zfs. Btrfs has quite a few more accidental readers.

Didn't Fedora transition to BTRFS as default in 33? I'm eager to see reports from that.

It did, but as far as I know it's effective on fresh installs only. It would be too risky to migrate automatically to Btrfs from ext4 during the 32->33 upgrade. I suspect a lot of users upgraded to 33 from 32 without seeing any problem with sticking with ext4 (including me). As a result, a lot of users are still using ext4.