On Thu, Nov 21, 2024 at 11:39:24PM -0500, Eric Renfro via talk wrote:

I mean, a number of distributions are defaulting to BtrFS. The exception is, Ubuntu. Because for some reason, Ubuntu wants to suggest and push ZFS, but only on their main edition, Ubuntu actual. Every other spin doesn't offer ZFS but instead lets you install using BtrFS. Even Ubuntu Server edition lets you use BtrFS.

Fedora defaults to BtrFS. OpenSUSE defaults to BtrFS.

EndeavourOS, can use BtrFS, though not sure if it's necessarily default or not. Debian lets you install with BtrFS, in both standard install and Live install (Calamares based).

Anyway, all that asside, I've been using BtrFS a good part of 10~15 years now, and with great success mind you. I use it extensively including bootable snapshots, use of snapper, and I've done so with distros like Ubuntu (manually), Linux Mint (Post install script modifications), LMDE (same with scripting), Debian (Manual during install), Fedora, and EndeavourOS (Even better setup with customized installation as per their user_commands.bash approach).

I only poked btrfs briefly very early on. I decided to try it on my laptop (which was the one before my current one, so it has to be at least 13 or 14 years ago now, given this is 12 years old), and quickly decided that a filesystem that would tell you it was out of disk space when writing files while also claiming to have multiple gigabytes free, and should have that much free based on the size of the drive and the files I put on it, was just not something I needed to deal with. A filesystem that says 'disk full' while df reports space available is just not user friendly. I hope that has improved since. Of course since I have had no interest in snapshots or any of the other neat features, I just haven't gone back. Of course I also have had no interest in looking at ZFS either since I also didn't need its features, nor the potential license hassles. -- Len Sorensen

I use BTRFS on a number of Fedora systems. It doesn't seem to be very different from extx, mostly because I don't use any of its new features.

From: Ron / BCLUG via talk <talk@gtalug.org>

...

Possibly ZFS-adjacent but without the nightmarish license problems?

There are no nightmarish license problems with ZFS.

There's an issue where the license isn't GPLv2 compatible, but they're quite similar in spirit.

As a user, it has no impact on me and works great.

If your distro complies with the GPL and the Sun / Oracle ZFS License, there is a problem. Ubuntu seems to disregard this.

Most dev work for ZFS is now done on Linux as I understand it - no longer a second-class citizen on our favourite platform.

As I understand it, this is true of the open source fork of ZFS. Oracle continues to develop a closed source version but none of that code is open. As I understand it, the memory management of ZFS doesn't mesh perfectly with the Linux kernel. A legacy of its Solaris origin.

...

Am I missing something?  It's in the kernel, but if it was that good, lots of distros would be defaulting to it ... and they're not.

Yeah, in fact, RedHat has removed it as of RHEL 8:

...

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/htm...

Yes. Kind of scary. But Fedora uses it as the default so that is probably the future for RHEL.

On Mon, 25 Nov 2024 at 09:52, David Mason via talk <talk@gtalug.org> wrote:

btrfs looks really interesting. And it's good to have an alternative to zfs, but for me, it's not yet ready for prime time.

If you have a serious amount of data that you care about, mirroring and raid1 are jokes. (See https://jro.io/r2c2/ for comparisons of what various raid levels do for you.) With disks the size they are these days, you have a fair chance of another disk failing while you're re-building the checksums from a failed disk, and if you get read errors during the process, you'll never know. So raidZ2 (what btrfs calls raid5) is a minimum. (Note that this is a particular problem if you bought a bunch of the same disks (because they were a great deal) manufactured near the same time. We have noticed contemporaneous failures!)

btrfs raid5/6 have some serious issues - a search following one of the links in the wikipedia article to: https://lore.kernel.org/linux-btrfs/20200627030614.GW10769@hungrycats.org/ and putting "raid5" in the search turns up numerous issues from the last couple of months; the SUSE support page describes a lot of (to me) very scary errors.

So I'll stick with ZFS, particularly as the license issue seems to be "ancient" history.

I used an off-hand expression in my discussion of ZFS, and as usual I'm paying for that. It's fairly easy to use ZFS with Linux, so my characterization of "nightmarish license problems" was ... hyperbole. But on Debian at least, which honours both the GPL and the ZFS licensing, the system must download and build the ZFS kernel drivers every time there's a kernel update. This is because OpenZFS inherited the deliberately obstructive licensing from Solaris that - although otherwise "open source" - does not allow shipping binaries to a GPL system. As I understand it, this was intentional on the part of Solaris and relicensing with the hundreds of developers who submitted code under that license is essentially impossible. If Ubuntu is shipping ZFS binaries with the Linux kernel, they're breaking license rules. They may not care, but distros like Debian who have less lawyers on tap and a stronger moral compass may not feel comfortable doing this. What this means in practice is that a weekly `apt update && apt full-upgrade` that includes a kernel averages 1-2 minutes on most Debian machines that don't have ZFS installed, and 10 minutes on machines that do have it installed. This is a significant PITA (although not, I admit, "nightmarish"). It means an action you thought would be short - is not. It's enough that I've learned to avoid ZFS on my desktops and only use it on multi-drive systems - and even there I find it a bit annoying. Thanks everyone for the comments on btrfs: I managed to do a bit more research in the intervening time, and it amounted to everything everyone said on this list. Btrfs is good but there are a couple significant blocks: lack of native encryption, lack of good RAID 5/6, lack of complete recovery tools (still being developed). Developing file systems must be particularly hard: beta software at worst wastes your time, beta FSes at worst nuke your data. Slightly different risk levels. -- Giles https://www.gilesorr.com/ gilesorr@gmail.com