There's A Proposal To Switch Fedora 33 On The Desktop To Using Btrfs

[240Hz]

BTRFS is extremly slow on the Desktop

[depau]

I love btrfs and I use it on all of my devices. However, it does not handle running out of space better. I filled it up by mistake recently and I couldn't even `rm` files to free up space. I had to delete some subvolumes and truncate some large files before I was able to use it normally again.

[Jabberwocky]

BTRFS is moving ahead with big steps. I follow the mailing list and there are tons of cleanups and improvements. Sure there are still things that needs improvement, but there is an amazing amount of improvements happening. If you track the LTS kernels you are VERY unlucky if you encounter some issues..

+1 I've been using btrfs for more than 8 years on my workstation(s). I had many frustrating problems mostly with bad quality of repair tools and lost some data along the way. More compatibility issues with docker/swap, but the experience has been much better the past 2 years. I still use ext/xfs/zfs/overlayfs in some places, but have started to use btrfs much more frequently. It really has some awesome bells and whistles.

[tildearrow]

andyprough Speaking about openSUSE..

https://lists.opensuse.org/opensuse-factory/2020-06/msg00328.html

Soon...

KDE Will NOT Be Dropped. Please.

[polarathene]

I love btrfs and I use it on all of my devices. However, it does not handle running out of space better. I filled it up by mistake recently and I couldn't even `rm` files to free up space. I had to delete some subvolumes and truncate some large files before I was able to use it normally again.

I thought that was a bit odd for a feature too. It's definitely improved on that front though over the years.. In 2016 for example I think the filesystem just ended up corrupted and I wasn't able to restore it if I ran out of space.

I don't think `rm` would have been that helpful? BTRFS differs from other file systems due to the CoW, so unless one of the improvements was to let you free up space that way, last I knew it allocated data and metadata blocks, which might not always be fully used, so you could try to run a balance to pack that data and possibly free up some empty blocks(data or metadata) so that you could do whatever it was you needed.

The btrfs tools are meant to handle such situations much better now and I think some space is reserved for that type of situation to recover from it. At the very least it doesn't end up in an irreparable state anymore afaik?

Another option is an external drive / stick that can temporarily be used to add to the storage pool, iirc though that may transparently adjust filesystem behaviour if you were previously on a single disk, where it starts writing data / metadata as DUP or something and you need to revert that when switching back to single disk. Pretty sure it's mentioned in the BTRFS wiki somewhere.

[CommunityMember]

At the very least it doesn't end up in an irreparable state anymore afaik?

There are still cases where one needs to use under-documented processes to recover in single user mode (a simple fsck is not sufficient). But while those cases exist, for most desktop uses (a single disk on the system) one will never hit them.

One of the strongest arguments for btrfs being the default is the additional recovery capabilities offered by snapshots, and one of the strongest argument against btrfs being the default is the benchmarking results posted here on Phoronix showing that performance wise it is still beaten by ext4 for most use cases.

[ZeroPointEnergy]

Why would anyone use a distro that doesn't support BTRFS in 2020? Silent corruption is a thing and backups wont protect you from it

[geearf]

Is there any point on using it on desktop?

Yes, for starters:
Compression? Yes.
Data checksum? Yes

[MadeUpName]

Ummm. F____ no!!!! While BTRFS has some merit on the server, on the desktop ... hell no. I spend about half my time on the desktop editing movies and pictures and a copy on write file system is shite for that.

[Space Heater]

I would have hoped they would talk about the real world performance differences between btrfs and ext4/xfs, and back that up with real benchmarks. The additional features of btrfs are of course a win, but it doesn't sound like any existing tooling on Fedora will take advantage of them before Fedora 33 is released, and as a result typical end users will not see any immediate benefit. The sales pitch seems to be that switching to btrfs will maybe/hopefully/eventually result in more upstream development and make the ecosystem better, which comes off as pretty dubious to me.

Also I'm not very comfortable with defaulting to a filesystem where a developer said this month that "We have far too many real data loss bugs in btrfs already".