Bcachefs Working Towards Online Fsck, Faster Mount Times

[re:fi.64]

My impression was that BcacheFS started with all the easy stuff while BTRFS tacked all the hardest problems first.

Which just why BTRFS is the most stable Linux filesyst—oh, wait...

Bcachefs is trying to solidify the core design before moving on to the bigger stuff. Sometimes it's the little things that will screw you over...

[flower]

I use ext4 with LVM Cache.
Has bcachefs any advantages I should know?

[waxhead]

First, ZFS and XFS are competitors:

XFS is extremely fast and stable but has developed about as far as it can go... it's hard to add features without breaking underlying design.
ZFS is extremely safe and stable but the speeds suffer greatly in return for the data safety features. The features currently added are insane and they work really well... but the license is problematic for widespread adoption. Also configuration isn't as user friendly or flexible.
BTRFS is extremely fast and has a lot of cool features... but it widely inconsistent and is slower than ext4 (the fastest one) and unstable compared to ZFS.

Second, in those regards, I think Bcachefs will be faster than ZFS, have cooler features than XFS, won't eat your data like BTRFS, and be flexible to configure.

I remember when BTRFS just came out and it was a joke. I'm using Bcachefs on my daily machine and it hasn't had nearly the same issues that BTRFS had around it's age.

Well for the reasons you point out ZFS and XFS are really not (today) competitors to BTRFS. ZFS is the closest one (and a damn good filesystem), but as you point out license issues is one thing and configuration is another. Nothing is (as far as I know) as flexible as BTRFS in terms of adding/removing disks to the pool.

XFS is nice, and they are adding a lot of things such as subvolumes, copy on write and so on , but lacks a few flexibility things such as shrinking the filesystem (which is the most common complaint). It's nice , but not quite there yet.

What do you mean by saying that BTRFS is inconsistent? I have been using BTRFS since before 2013 (if my memory serves me correctly). I still use the same filesystem created back then , but have grown it and added disks to the pool. Some years ago I converted my rootfilesystem to run on this filesystem as well. I have not had a single issue, btrfs have saved med from more than one data corruption, a disk controller failure, a dropped out disk, an dd accident where I overwrote the first 256mb of one of the disks in the BTRFS pool. The system survived all of these without a glitch and with the exception if the disk controller failure and the dropped out disk all was fixed online. As for the command line tool it seems to be VERY consistent the way I have been using it at least.

There are quite a few myths in the community today. I won't even mention system something something, and BTRFS eating your data is one of the myths. I have been following the mailing list since about 2010 and usually when there is a horror story it has to do with either some weird setup, the raid5/6 (which is unstable) features, or btrfs with bcache(!) which seems to be a bad mix.

And yes, BTRFS *was* a unstable mess and had nasty bugs using just about any feature, but as a basic filesystem it has worked quite well. That really changed around kernel 4.0 - 4.4 and things are what I would consider mature and stable now (just as long as you know what you are doing). I also have my hopes that bcachefs will become a decent contender and perhaps I will switch to it someday , but as it is right now BTRFS is far ahead.

[blackiwid]

I think the problem with Btrfs has different reasons:

1. the Systemd effect, tribalism, fanboys of ZFS and Freebsd that just hate on it cause a part in their brain got triggered, they will refer to 1 or 2 reports of data loss 5 years ago for the next 20 years and will never check if something changed. They have their final opinion and nothing can change it.

2. the/a advantage of Btrfs is also it's disadvantage. It works better than zfs for small setups with low ram, with rootfs with small disks etc. While when you got over to invest the 2000 Dollars to have a 500W Zfs server (yeah I know I overdue a bit, but not that much) it runs well. with it 32gb ram etc.
While people tend to run into more issues with their max 8gb ram systems with nearly full disks all the time.

3. The talk about real hard unrecoverable data loss and Btrfs is way exaggerated but there is some sort of softlocking that probably many people run into. So if your partitions especially root is pretty full or you use snapshots and make it full that way. it fast can get in this state where it doesn't allow to write files. I think it then even refuses to boot into a Window manager.

That means you have a downtime then you have to add maybe a usb-stick as temporarily space to delete files so that it can get in a working state again. You need for that 5-10 very cryptic console commands (imho) which I am not sure about ZFS but with ext4 or xfs I never have such issues.

And the Drive is technically not even 100% full before that happens, with data that is. Somehow if you not do some maintaining it can eat a big part of your drive with metadata.

Such problems mixed with bad tooling, that as example don't give you good Diskfree numbers, is sometimes painful. And people sometimes then say it's not worth to fix it maybe because they had other problems with the system before too, and then install a new OS. That is then a felt data loss. Even if it would been recoverable.

About using the Snapshot features for system updates, you can solve that problem also on another level, I use Nixos, there I get this on a distribution level.

I think many problems with Btrfs is that it get's used by users for rootfs or very small setups which this filesystems are not made for. Yes Btrfs is better on that field than ZFS but that does not mean that CoW Filesystems are good at that field.

Btw a stupid question according to wikipedia xfs is a CoW filesystem since 2 years with reference to a phoronix article:
https://www.phoronix.com/scan.php?pa...Shared-Extents

Doesn't that mean that eventually it will have most/all features ZFS and Btrfs have or at least the most important ones, especially with Redhat behind the development?

[jpg44]

Btrfs is actually a very good filesystem. So we see a lot of disinformation about it, reliability problems from its early days when it was still in the early phases of development. A lot of work has gone into improving features such as RAID. The problems people had with btrfs related to the RAID 5/6. People were warned in the documentation not to use RAID 5/6 because it was still not working properly, but many ignored this and did anyway, then when they have problems, they think the whole filesystem is bad and just want to go back to EXT4.

Meanwhile the RAID 5/6 problems have been fixed, and btrfs is a very reliable filesystems and has matured with a set of rich features. Yet people are still trapped in this mentality that btrfs is buggy and reliable. Its because people get these highly simplistic ideas in their head about things, that since it has a problem years ago, btrfs will always be the unreliable filesystem in their minds. The fact is its bean mature for years, and RAID 5/6 is really the last feature that needed to be matured, because its a particularly complex problem.

Its very similar to how people think about X for instance. In the 1980s a book came out called Unix Haters Handbook. The books contents are largely antiquated nonsense and has long ago lost its relevance. One of the books complaints was X is bloated and slow. Well, on most computers in the 1980s, you had a few MB of RAM, so any GUI by its nature is going to be bloated and slow, it does not matter what GUI you used. But people got this idea in their head that X is bloated and slow, and its become sort of this urban legend, people are unable to shake this idea that X is bloated and slow. Thats despite the fact that X protocol core uses just a few MB of RAM, on modern hardware where RAM is in the GBs, its downright lean. Your average GTK app running on Wayland seems to consume for a some fairly basic things 100 MB or more right off the bat, because of the heavy use of UI special effects and pixmap data rather than vector UI elements.

The "X is slow" mental illness and lie has resulted in years of effort being thrown away to create the totally unnecessary and wasteful Wayland projects which did not solve any problems in reality or give us anything we dont already have. Linux already has a Window System, so we didn't need a new one. Yet people wasted years of effort to basically re-implementing something we have. They could have instead used that time to implement something we don't have, in particular voice recognition, which is a popular feature for many users and would increase Linux's desktop appeal. By wasting time and effort on Wayland, Wayland actually held back and impaired Linux's desktop appeal by taking man hours away from doing something we don't have like voice recognition. And it was all because of a big fat lie that X is bloated and slow.


We see the same thing with filesystems. People get into their heads that btrfs is unreliable, even when its not true they cannot let go of the idea, so then they waste years more of effort recreating another filesystem rather than making btrfs better. What you end up with basically is a bunch of half baked filesystems none of them being really great and a lot of wheel reinvention going on reimplementing the same stuff over and over again.

[Vistaus]

Btrfs is actually a very good filesystem. So we see a lot of disinformation about it, reliability problems from its early days when it was still in the early phases of development. A lot of work has gone into improving features such as RAID. The problems people had with btrfs related to the RAID 5/6. People were warned in the documentation not to use RAID 5/6 because it was still not working properly, but many ignored this and did anyway, then when they have problems, they think the whole filesystem is bad and just want to go back to EXT4.

Meanwhile the RAID 5/6 problems have been fixed, and btrfs is a very reliable filesystems and has matured with a set of rich features. Yet people are still trapped in this mentality that btrfs is buggy and reliable. Its because people get these highly simplistic ideas in their head about things, that since it has a problem years ago, btrfs will always be the unreliable filesystem in their minds. The fact is its bean mature for years, and RAID 5/6 is really the last feature that needed to be matured, because its a particularly complex problem.

Its very similar to how people think about X for instance. In the 1980s a book came out called Unix Haters Handbook. The books contents are largely antiquated nonsense and has long ago lost its relevance. One of the books complaints was X is bloated and slow. Well, on most computers in the 1980s, you had a few MB of RAM, so any GUI by its nature is going to be bloated and slow, it does not matter what GUI you used. But people got this idea in their head that X is bloated and slow, and its become sort of this urban legend, people are unable to shake this idea that X is bloated and slow. Thats despite the fact that X protocol core uses just a few MB of RAM, on modern hardware where RAM is in the GBs, its downright lean. Your average GTK app running on Wayland seems to consume for a some fairly basic things 100 MB or more right off the bat, because of the heavy use of UI special effects and pixmap data rather than vector UI elements.

The "X is slow" mental illness and lie has resulted in years of effort being thrown away to create the totally unnecessary and wasteful Wayland projects which did not solve any problems in reality or give us anything we dont already have. Linux already has a Window System, so we didn't need a new one. Yet people wasted years of effort to basically re-implementing something we have. They could have instead used that time to implement something we don't have, in particular voice recognition, which is a popular feature for many users and would increase Linux's desktop appeal. By wasting time and effort on Wayland, Wayland actually held back and impaired Linux's desktop appeal by taking man hours away from doing something we don't have like voice recognition. And it was all because of a big fat lie that X is bloated and slow.


We see the same thing with filesystems. People get into their heads that btrfs is unreliable, even when its not true they cannot let go of the idea, so then they waste years more of effort recreating another filesystem rather than making btrfs better. What you end up with basically is a bunch of half baked filesystems none of them being really great and a lot of wheel reinvention going on reimplementing the same stuff over and over again.

You're also a victim of the urban legends. No voice recognition on X? theShell uses voice recognition on X for its built-in AI assistant: https://vicr123.com/theshell/#
Also, while GNOME is bloated, GTK is rather lean (in comparison to GNOME!). I've never ever seen a GTK app use more than 30 MB right off the bat on Wayland.

[profoundWHALE]

There are quite a few myths in the community today. I won't even mention system something something, and BTRFS eating your data is one of the myths.

I have tried btrfs three times. Once in 2013, once in 2015 (one of those was a Fedora install), and once a month ago when it ate several terabytes of data while in (12TB + 12TB mirror) RAID10. That should never happen. I luckily had a backup on some older hard drives formatted with XFS. In 2013 I had it as the root partition and one day it would not boot and the partition was borked. In 2015 I had major performance issues related to it that continued to slow down the system until it no longer functioned.

So I will never trust btrfs. I wasted 2 weeks trying to recover it and the best I got was cp to some spare hard drives and see what fails and what doesn't. Every time someone says "Oh, well that was true in YYYY, but now it's so good!" I can't believe them.

A filesystem meant to replace ZFS/ext4/XFS, or whatever, shouldn't have unrecoverable data loss with something like RAID10, ever. I can't stress how incredibly incompetent it is to have a filesystem that was started about 9 years ago and still has these issues. It's great that you weren't burnt, but when I expect that thing to be rock solid and I almost lost wedding footage among other things which I would NEVER be able to just redownload or recompile or reinstall.

[anarki2]

I've been using ZFS as root for my Antergos desktop for 3 years now with ZFS as my go-to for random drives before that. Untuned or not implemented correctly, ZFS sucks regardless of where it's being used; I consider that statement true for all file systems.

ZFS only sucks on the desktop because there aren't any good graphical tools (gparted-esque & time machine like tools), snapshots aren't implemented in update utilities, GRUB doesn't support the newest features for /boot on a zpool, other bootloader solutions aren't that great, and the ram requirements aren't geared towards desktops (assloads of registered ECC ram aren't common on desktops).

ZFS has most of the bits and pieces in place that most of us want, it just has a high degree of difficulty to use and higher than usual requirements (especially for things like deduplication) compared to damn near every other file system. Once you get used to it and its features, it's hard to go back.

I'm just saying that I wouldn't call it useless on the desktop. Being able to snapshot before a pacman -Syu, a full blown emerge system rebuild, an Ubuntu dist-upgrade, doing some editing under /etc, or before doing whatever system breaking activity is great...especially when your desktop doubles as your work\home business PC. My last bad Windows update had me down for days until I reinstalled Windows (should have just reinstalled but I tried to fix it first). My last bad Antergos update had me down for minutes while I added /snapshot/ to my root pool's location (I always leave at least one kernel untouched during an update just for that...one that should boot both the updated system and the snapshot since I don't have a method to snapshot Grub and then boot into the snapshotted Grub...knows how, just too lazy to implement).

Such comment was bound to be made, maybe I should've linked this in advance:

https://forums.freenas.org/index.php?threads%2Fsingle-drive-zfs.35515%2F#post-216140

Teaser:

Well, the CTO of iXsystems said something like "single disk ZFS is so pointless it's actually worse than not using ZFS".

And on the desktop you rarely use pairs of disks. Especially in laptops.

[waxhead]

I have tried btrfs three times. Once in 2013, once in 2015 (one of those was a Fedora install), and once a month ago when it ate several terabytes of data while in (12TB + 12TB mirror) RAID10. That should never happen. I luckily had a backup on some older hard drives formatted with XFS. In 2013 I had it as the root partition and one day it would not boot and the partition was borked. In 2015 I had major performance issues related to it that continued to slow down the system until it no longer functioned.

So I will never trust btrfs. I wasted 2 weeks trying to recover it and the best I got was cp to some spare hard drives and see what fails and what doesn't. Every time someone says "Oh, well that was true in YYYY, but now it's so good!" I can't believe them.

A filesystem meant to replace ZFS/ext4/XFS, or whatever, shouldn't have unrecoverable data loss with something like RAID10, ever. I can't stress how incredibly incompetent it is to have a filesystem that was started about 9 years ago and still has these issues. It's great that you weren't burnt, but when I expect that thing to be rock solid and I almost lost wedding footage among other things which I would NEVER be able to just redownload or recompile or reinstall.

Care to share some details? How many disks , what kind of setup? Post to the mailing list? etc etc... I would love to dig into this a bit.

[re:fi.64]

The "X is slow" mental illness and lie has resulted in years of effort being thrown away to create the totally unnecessary and wasteful Wayland projects which did not solve any problems in reality or give us anything we dont already have.

That was literally never the main point of Wayland. It exists because:

- The Xorg architecture is inherently insecure. The fact that any application can literally be a keylogger is a major issue.
- The internal architecture is a mess, and there are a large amount of poorly documented extensions for compositors to implement. Building your own X11 WM/compositor with all the features these days is a mess.... Compare that to Wayland, where you can build a decently working compositor with wlroots with a relatively small amount of code.

Also, ITT: people who assume that if BTRFS worked for them, it must work for everyone.