search

pop-os / pop

A project for managing all Pop!_OS sources
https://system76.com/pop
2.47k stars 87 forks source link

Use btrfs by default #1945

Open vega-d opened 3 years ago

vega-d commented 3 years ago

BTRFS have gotten pretty much perfect. I personally have been using pop on btrfs for quite a long time. Fedora switched to btrfs as a default file system to use too. I don't see a reason to not use a better FS.

mmstick commented 3 years ago

Better in theory, but not in practice. I would generally classify it as a virtual woodchipper, rather than a file system.

https://arstechnica.com/gadgets/2021/09/examining-btrfs-linuxs-perpetually-half-finished-filesystem/

ZFS is superior to Btrfs, and bcachefs is also a promising Btrfs replacement. XFS on LVM is also potential. We'll see in the future.

vega-d commented 3 years ago

https://arstechnica.com/gadgets/2021/09/examining-btrfs-linuxs-perpetually-half-finished-filesystem/

I thoroughly read the article you linked, and overall image I got is that btrfs is completely fine on single disk systems and only really sucks in raid arrays.

I don't think raid arrays are used that oftenly on desktop systems where pop os is deployed, so saying using btrfs for single drive usage is bad because raid support is bad is not really doing anything.

altsalt commented 3 years ago

After battling "drive full" errors over the last month despite have 10gb+ free, things got into an unbootable state after moving some large video files. Quite a bit of debugging later, it turns out that BTRFS needs more free space than the files being deleted. Unsure how my PopOS install ended up with this filesystem in my LUKS/LVM multi-boot, but I'd say that BTRFS isn't ready for prime time. Stick with Ext4 for single drives and ZFS for multiple (now that there's a community agreed upon ZFS).

Schykle commented 3 years ago

Just tossing my two cents in the well here.

I've been using BTRFS in production for at least four years now, and it's been rock-solid. After many discussions I've seen during Fedora's proposed (and accepted) transition to BTRFS, I've seen most of the opposition cases not actually be relevant to the resulting implementation of BTRFS in production, as well as very specific cases which are intentionally designed to break the filesystem, but not occuring in actual use.

Unless the default configuration is parity RAID, which I doubt is the case.

BTRFS is by no means perfect, but for desktop use it continues to prove itself through openSUSE, now Fedora, and Garuda. The most dangerous part of BTRFS comes down to how it's configured. The benefits it offers for easy volume/subvolume management without causing many of the issues that programs run into with LVM volumes (such as failed distro installers and disk management apps), as well as the benefits it offers for compression and snapshotting are incredibly useful.

Maybe there's another direction that might work in the future, but at the moment ZFS comes with a lot of baggage for desktop use when you consider the memory overhead and the nature of configuring ARC on something that gets tossed on a super wide variety of devices. BTRFS is younger, but still very capable.

mys31f commented 3 years ago

To be honest, there are other distributions that have already moved over to BTRFS. Sure, it might not have the maturity of EXT4, but for what most people do and use on a daily basis, it's perfectly fine. Most of us don't even have RAID arrays on our systems anyways. Honestly, BTRFS works out really well for me, on multiple distributions for that matter. The snapshotting system on BTRFS would help a lot with backing up systems also.

TeamLinux01 commented 2 years ago

I wouldn't mind if the auto-partitioner had the option to use Ext4 or BrtFS and set Ext4 as the default.