Btrfs SIG Established For Advancing Btrfs Interests On Fedora

[phoronix]

Phoronix: Btrfs SIG Established For Advancing Btrfs Interests On Fedora

While Fedora Workstation has defaulted to using the Btrfs file-system for the past four years, only this past summer was the idea raised of creating a Fedora special interest group (SIG) around Btrfs to help advance efforts around this CoW file-system for Fedora Linux integration. This week marks the Fedora Btrfs SIG officially being established...

https://www.phoronix.com/news/Fedora-Btrfs-SIG-Established

[hamishmb]

Sounds good, I only ever used Btrfs once on two different systems, and both got unrecoverable corruption a little while later.

That said, I used the EXT4 converter which at least at the time wasn't recommended, so I may have shot myself in the foot there.

Regardless, my negative experience with Btrfs was a very long time ago now, probably back in 2016 or so, so I imagine it's a lot more stable now.

[woddy]

Great news, now you can get contributions from Fedora as well as SUSE and others.
More and more distributions are using btrfs, including the upcoming KDE distribution.

Edit. I have been using Btrfs in openSUSE for over 5 years on my PCs and have never had any problems.

[skeevy420]

I wish I could get myself to be excited over this but I just can't. Everything that BTRFS does good, OpenZFS does better.

At the end of the day Linux needs a file system with better built-in volume management than the Linux Statue Quo of the LVM/DM/FS ClusterFuck. The in-tree file systems with volume management, Bcachefs and BTRFS, have the same limitations regarding using individual per-subvolume settings that OpenZFS doesn't have.

I'm not trying to be as Pro-OpenZFS as I am trying to voice my overall frustrations about the state of in-tree Linux file systems and volume management going into 2025.

[luckylucky]

I keep using EXT4 on Fedora until there's a compelling reason to change.

[Quackdoc]

but why? What are the actual goals this intends to accomplish?

[Vermilion]

but why? What are the actual goals this intends to accomplish?

Reading the original announcement may be one good way to find out:

Some of us working on Btrfs in Fedora have decided to start a SIG to foster both better coordination, and also provide an easier way for others in the community to get in touch.

We definitely have more Btrfs enablement to pursue in the future - bootable snapshots being one, transparent encryption another (pending it making it into the upstream kernel) [...]

Our goal is to deliver the highest quality experience leveraging the capabilities Btrfs has to offer [...]

[q2dg]

I would like Stratis (https://stratis-storage.github.io) was taken seriourly

[Mitch]

Reading the original announcement may be one good way to find out:

I imagine they could use snapshotting as a part of or replacement of certain functionality in their atomic distros' functionality. You could make a subvolume w/ all your system stuff snapshottable and then your system is protected from all of issues like power outages. So lots of the benefits of atomic distros supported at the filesystem level instead.

[Quackdoc]

Reading the original announcement may be one good way to find out:

"Some of us working on Btrfs in Fedora have decided to start a SIG to foster both better coordination, and also provide an easier way for others in the community to get in touch."

This is not a goal, this is "I wanna do stuff, wanna do stuff with me?"

"We definitely have more Btrfs enablement to pursue in the future - bootable snapshots being one, transparent encryption another (pending it making it into the upstream kernel) [...]"

this doesn't seem to be in the original post, but do these two things warrant creating a sig for it? I assume there are other things, but it would be nice to know what they are.

"Our goal is to deliver the highest quality experience leveraging the capabilities Btrfs has to offer [...]"

A mission statement, I don't consider vague statements like these to be "actual goals" it's not that useful in determining the worth of a dedicated sig