Bcachefs Merges Support For Btrfs-Like Snapshots

[cynic]

I just hope it gets merged soon....

don't hurry.
if it get mainlined too early it will incour into the same issues that happened to btrfs: bad reputation for initial bugs, harder to fix things and so on.

[skeevy420]

don't hurry.
if it get mainlined too early it will incour into the same issues that happened to btrfs: bad reputation for initial bugs, harder to fix things and so on.

Exactly. I'd rather them get their ducks in a row than to update my kernel, see a new knob, and then compress GRUB with something it shouldn't be compressed with.

Guess who did that with BTRFS?

[useless]

Oh, I love btrfs: https://unix.stackexchange.com/quest...how-to-recover

wanted 724347 found 724505

That's missed writes. Bad hardware/firmware or another component in the stack. It always amuse me the 'it broke itself!'

[mdedetrich]

RAID5 is a joke, period. Even without btrfs.

Raid5 without ZFS is a joke, RAID with ZFS is fine as the ZFS implementation of Raid5/6 fixes the main issues associated with RAID 5/6 (i.e. write hole)

Raid5 on btrfs is even worse because Btrfs advertises itself as being a secure filesystem that doesn't lose your data. At least there is a warning now.

[Deathcrow]

That's missed writes. Bad hardware/firmware or another component in the stack. It always amuse me the 'it broke itself!'

Also the first thing I see:

WARNING: Do not use --repair unless you are advised to do so by a developer or an experienced user, and then only after having accepted that no fsck can successfully repair all types of filesystem corruption. Eg. some software or hardware bugs can fatally damage a volume. The operation will start in 10 seconds.

Why do end users always think they know better than the devs who put the warning there? Maybe the btrfs-progs devs should set a code for --repair, that you can only get past by asking on the mailing list or looking at the source.

People who think that BTRFS is unstable in every day use cases are really weird. It's used on thousands of servers at my work, also AFAIK facebook uses it for their container/cloud infrastructure. It doesn't magically fail, unless hardware is broken or you do something weird & out of scope.

[RahulSundaram]

I truly don't get the ZFS license issue...the "it's the wrong kind of open source" issue. I get the kernel maintainer reason, but for the average user that seems like a weird place to draw a line in the sand (especially when they're NVIDIA GPU users...not saying you are, just in general)

A filesystem is not a leaf application. What the distribution supports can matter a lot to users. Without distribution support, it is not straightforward to integrate the filesystem into the installer, root etc and you have to do it after the fact and therefore you don't get the automation support like kickstart or yast and you get limited or non existent vendor support from folks that need to integrate closely with the filesystem. Many people are learning Linux because of what they do at their jobs and if their workplace is running say either RHEL (or one of its many derivatives) or SUSE, they don't get any kind of distro integration and likely adoption is low because of it. Nvidia isn't quite the same situation really because many support it including enterprise distros and filesystems are lot more critical than a graphics driver. Nevertheless there is certainly people choosing to use AMD for similar reasons including commercial organizations.

[birdie]

That's missed writes. Bad hardware/firmware or another component in the stack. It always amuse me the 'it broke itself!'

Does it bloody matter when fsck.btrfs is unable to fix the issue?

Unless you cat /dev/urandom > /dev/partition e2fsck fixes pretty much everything (if HW is working properly). Sorry, as an old timer I just refuse to use fancy new filesystems which drag people down.

[skeevy420]

A filesystem is not a leaf application. What the distribution supports can matter a lot to users. Without distribution support, it is not straightforward to integrate the filesystem into the installer, root etc and you have to do it after the fact and therefore you don't get the automation support like kickstart or yast and you get limited or non existent vendor support from folks that need to integrate closely with the filesystem. Many people are learning Linux because of what they do at their jobs and if their workplace is running say either RHEL (or one of its many derivatives) or SUSE, they don't get any kind of distro integration and likely adoption is low because of it. Nvidia isn't quite the same situation really because many support it including enterprise distros and filesystems are lot more critical than a graphics driver. Nevertheless there is certainly people choosing to use AMD for similar reasons including commercial organizations.

But that describes a lot of file systmes, not just ZFS. I just mean that there's next to no installer or root support for other file systems either and yet they exist and are suggested for certain situations...like NTFS, Resier, Bcachefs, F2FS, JFS, etc. From there, level of support varies by distribution and what you're using. For example, Ubuntu has stellar Stratis support (that's a joke).

As far as distribution adoption....it's mixed. Some have it, some don't. Most of those that don't you can find a repository on the OpenZFS website (as well as links to support documentation). To me, that's similar to NVIDIA where it's either in the repos or you can go to the vendor and get a driver. In that regard, OpenZFS supports more distributions than AMD's Pro/commercial driver.

[useless]

Does it bloody matter when fsck.btrfs is unable to fix the issue?

How do you pretend to fix a hardware issue with a --repair (fsck.btrfs isn't a thing)? You have restore to try and salvage data.

(if HW is working properly)

Do you see what's wrong with your statement?

Unless you cat /dev/urandom > /dev/partition e2fsck fixes pretty much everything

Yeah, and it will give you whatever was written (or not) when your stack missed writes. It makes no guarantee whatsoever about the correctness of the data you get.

Sorry, as an old timer I just refuse to use fancy new filesystems which drag people down.

Then you miss one of the main benefits of these fancy new filesystems:

Bacik concluded with a summary of what has worked well and what has not. He told the story of tracking down a bug where Btrfs kept reporting checksum errors when working with a specific RAID controller. Experience has led him to assume that such things are Btrfs bugs, but this time it turned out that the RAID controller was writing some random data to the middle of the disk on every reboot. This problem had been happening for years, silently corrupting filesystems; Btrfs flagged it almost immediately. That is when he started to think that, perhaps, it's time to start trusting Btrfs a bit more.

Another unexpected benefit was the help Btrfs has provided in tracking down microarchitectural processor bugs. Btrfs tends to stress the system's CPU more than other filesystems; features like checksumming, compression, and work offloaded to threads tend to keep things busy. Facebook, which builds its own hardware, has run into a few CPU problems that have been exposed by Btrfs; that made it easy to create reproducers to send to CPU vendors in order to get things fixed.

In general, he said, he has spent a lot of time trying to track down systemic problems in the filesystem. Being a filesystem developer, he is naturally conservative; he worries that "the world will burn down" and it will all be his fault. In almost every case, these problems have turned out to have their origin in the hardware or other parts of the system. Hardware, he said, is worse than Btrfs when it comes to quality.

[RahulSundaram]

But that describes a lot of file systmes, not just ZFS. I just mean that there's next to no installer or root support for other file systems either and yet they exist and are suggested for certain situations...like NTFS, Resier, Bcachefs, F2FS, JFS, etc.

Yes, you said it yourself "certain situations". Outside of what distributions typically support natively within the installer and associated tooling - Ext3/4, XFS etc, adoption is quite low for any of what you listed as a general purpose filesystem.