Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Btrfs Coming to Fedora 33

fedoramagazine.org

Post reply on HN
Print view View original

71–80 of 140 posts

Re: Btrfs Coming to Fedora 33

#71

Post by nix23 »

Uberphallus wrote: post #52
ghaff wrote: post #51

Earlier quoted context omitted.

Because Fedora, among other distributions, will not include ZFS for licensing reasons. (Leaving aside any other discussion of the relative merits of ZFS and Btrfs.)

ZFS has a good share, if not 100%, of the same problems as Btrfs, and in the end of the day it's always matter of leaving files/directories/volumes without CoW, which is hardly a software rewrite as the grandparent insinuated, and more of a packaging issue.

>ZFS has a good share, if not 100%

ZFS has no Raid5 write-hole...no traditional Raid problems at all (z1/2/3)

>leaving files/directories/volumes without CoW

No...just NO, just for a special Cases like a Database.

Re: Btrfs Coming to Fedora 33

#72

Post by eptcyka »

KaiserPro wrote: post #23

I have no issues with BTRFS, apart from the documentation is really poor. I don't mind it becoming popular, but please for the love of $Deity can we please make the docs as good as ZFS. I will contribute cash if needs be. Facebook are utterly shit at documenting things, so yes it might work for their usecase, but they essentially store knowledge through Shamanism, which is terrible unless you're inducted into the wor…

I for one support Facebook's push to make more problems solvable solely by entering a mud hut and ingesting hallucinogenics.

Re: Btrfs Coming to Fedora 33

#73

Post by symlinkk »

filmor wrote: post #64
AdmiralAsshat wrote: post #55

There's probably no way to convert the legacy ext4+LUKS filesystem over, so, I guess I'll decide when F33 comes out whether I want BTRFS enough to do a clean install rather than an upgrade.

You can convert an ext4 filesystem to btrfs using btrfs-convert.

Is that stable?

Re: Btrfs Coming to Fedora 33

#74

Post by yjftsjthsd-h »

rkangel wrote: post #48
rwmj wrote: post #46

Earlier quoted context omitted.

Defaults to GNOME, firewall disabled, ext4 (and now btrfs) instead of XFS. (These spins are all about defaults - so installing Server doesn't make it any less useful for desktops, but you may have to dnf install a few things the first time you use it.)

What do you mean "defaults to GNOME"? Server defaults to no DE at all I thought (been a year or two since I've used it) and Fedora defaults to GNOME anyway. If it by default doesn't install email client and music players I don't use that might be nice though.

> What do you mean "defaults to GNOME"? Server defaults to no DE at all I thought (been a year or two since I've used it) and Fedora defaults to GNOME anyway.

The "workstation" version uses GNOME.

Re: Btrfs Coming to Fedora 33

#75

Post by chasil »

ansible wrote: post #58
ge0rg wrote: post #2

btrfs has made some headlines in the past about its severely broken checksum computation in RAID modes, which rules them out for production use, i.e. https://phoronix.com/scan.php?page=news_item&px=Btrfs-RAID-5... The wrong parity and unrecoverable errors has been confirmed by multiple parties. The Btrfs RAID 5/6 code has been called as much as fatally flawed It would be interesting to know if this has been addressed…

> For data, it should be safe as long as a scrub is run immediately after any unclean shutdown Note that btrfs-scrub (according to the docs) is looking for on-disk block errors, comparing the data to the CRC (or whatever algo) to see if that matches. If it can recover the original data, the bad block is re-written with the correct CRC. So btrfs-scrub does not find or fix any errors with the filesystem structure. For…

The latest mkfs.btrfs on my Oracle Linux 7 supports "crc32c, xxhash, sha256 or blake2."

The relative benefits are discussed in "man 5 btrfs" in the "CHECKSUM ALGORITHM" section.

    man 5 btrfs | col -b | sed -n '/^CHECKSUM/,/^FILESYSTEM/p'

Re: Btrfs Coming to Fedora 33

#76

Post by codys »

ansible wrote: post #56
ibotty wrote: post #6

Earlier quoted context omitted.

There are some modes that are horribly broken in btrfs (e.g. most of RAID except RAID1), but the common options are safe and in continuous use.

We've recently suffered a catastrophic failure with btrfs RAID-1 on two fileservers recently. They were both RAID-1 with two 4TB drives, stock Ubuntu 16.04. With one of the two, the filesystem was allowed to fill to 99% capacity (no automatic monitoring), so obviously that is operator error, and I'm not aware of any filesystem that can handle such situations gracefully. The system became unresponsive, with btrfs-tran…

My experience with btrfs is from a few years ago, so it's possible they've changed the semantics here since then, but this might be applicable:

Btrfs requires a regularly run administrative task via "btrfs balance". Balancing consolidates data between partially filled block groups, which will restore consumed space even if a block group is not entirely empty. Typically, one runs balance with a set of gradually increasing parameters to control the records affected (ie: bash script that starts with block groups that are more empty and proceeds towards ones with a higher percentage utilization).

In my experience with btrfs a few years ago, running a balance in some situations would result is incredibly high system wide latency.

The man page [1] does not appear to reference the free space issue directly, so I'm not sure if they've removed this need.

1: https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs-balanc...

Re: Btrfs Coming to Fedora 33

#77

Post by prussian »

vetinari wrote: post #17
bkor wrote: post #9

I've quickly skimmed the discussion on fedora-devel regarding btrfs. I wondered mainly how they'd handle the various cases where btrfs does not work well, e.g. files that change often inline (databases, VMs, etc). Apparently an application can tell to treat those files differently. So it's basically a matter of fixing various software to work nicely with btrfs as well as any similar filesystem. As mentioned in the th…

> I wondered mainly how they'd handle the various cases where btrfs does not work well, e.g. files that change often inline (databases, VMs, etc). It least for default libvirt locations fedora disables CoW (chattr +C). No change in software needed.

This is what I was thinking as well. It just means packagers have to be mindful of what kind of files their maintained software makes and to appropriately carry these metadata changes where they are needed. I don't really see an issue with this mindset.

Re: Btrfs Coming to Fedora 33

#78

Post by chasil »

viraptor wrote: post #28
bleepblorp wrote: post #22

For desktop use, what problem does btrfs solve better than lvm+ext4? Btrfs is slower than lvm+ext4, doesn't like working with large files, requires more ongoing maintenance (scrub, rebalancing), and is more prone to data corruption. Given that lvm can do snapshots under ext4, the only real benefit of btrfs is btrfs send, but for most use cases that doesn't seem like a large enough benefit to be worth the rest of brtf…

> requires more ongoing maintenance (scrub, rebalancing) I'm not sure that's a good description. Scrubbing is an option that you get extra. You don't need to use it and the behaviour won't be different than for example ext4 with regards to bad data detection. It's purely an extra feature. If rebalancing is useful for desktop users (wasn't really in my experience), I'm sure it will get a system-provided job that balan…

There are concerns with ZFS of the "scrub of death" on a system lacking ECC ram:

https://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-y...

There is some debate on this question:

https://arstechnica.com/civis/viewtopic.php?f=2&t=1235679&p=...

I'm curious if the situation is improved for BtrFS.

Re: Btrfs Coming to Fedora 33

#79

Post by ansible »

codys wrote: post #76
ansible wrote: post #56

Earlier quoted context omitted.

We've recently suffered a catastrophic failure with btrfs RAID-1 on two fileservers recently. They were both RAID-1 with two 4TB drives, stock Ubuntu 16.04. With one of the two, the filesystem was allowed to fill to 99% capacity (no automatic monitoring), so obviously that is operator error, and I'm not aware of any filesystem that can handle such situations gracefully. The system became unresponsive, with btrfs-tran…

My experience with btrfs is from a few years ago, so it's possible they've changed the semantics here since then, but this might be applicable: Btrfs requires a regularly run administrative task via "btrfs balance". Balancing consolidates data between partially filled block groups, which will restore consumed space even if a block group is not entirely empty. Typically, one runs balance with a set of gradually increa…

Interesting.

I would assume that this is not a factor with RAID-1, where all system, metadata, and data is duplicated. I could see this as being very important for the higher RAID levels.

We have since stopped deploying any sort of btrfs RAID (even RAID-1), and have gone back to using Linux MD.

Re: Btrfs Coming to Fedora 33

#80

Post by cpuguy83 »

Tsiklon wrote: post #21

Interesting - As RHEL is downstream of Fedora, I thought BTRFS was not being explored further by Red Hat, on account of their deprecation of it downstream in RHEL. If I recall this was because they didn't have the developers able to work on the software, preferring to use XFS + LVM to accomplish some of the goals of BTRFS as their STRATIS project. I wonder what this means for RHEL going forward in RHEL 9?

They stopped supporting it on RHEL (even experimentally) because the code churn was (is?) too high.

The thing to understand about RHEL is they backport... everything.... to ancient kernels.

Code that has lots of churn can be very difficult to backport, particularly to such an old codebase.

Post reply on HN