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

81–90 of 140 posts

Re: Btrfs Coming to Fedora 33

#81

Post by prussian »

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…

I can't speak for everyone, but in terms of administration, it's much easier to deal with than having to sort through the filesystem sundae you end up making with device mapper frameworks and the filesystem cherry on top of it all. In a humorous twist, subvolumes are basically thin provisioned logical volumes too and btrfs still had quotas to make them behave as such.

Re: Btrfs Coming to Fedora 33

#82

Post by DiabloD3 »

diffeomorphism wrote: post #68
DiabloD3 wrote: post #53

Earlier quoted context omitted.

Or switch distros. I'm pretty sure I can't replicate this bug on Debian or Ubuntu.

That is like asking to move to a different house because you don't like the color of the walls.

To use that analogy, no, its more like moving to a different house because lead paint remediation is too costly and error prone.

Re: Btrfs Coming to Fedora 33

#83

Post by rkangel »

boredishBoi wrote: post #63
rkangel wrote: post #48

Earlier quoted context omitted.

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.

I think the defaults they’re referring to are for fedora desktop, not server

Yes you're right - thank you. On a re-read I see that I had the assertions the wrong way round.

Re: Btrfs Coming to Fedora 33

#84

Post by wtallis »

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 reasoning for running a scrub after an unclean shutdown is not to catch corruption of the filesystem structure, but to catch data corruption resulting from the RAID5 write hole.

If you're not using RAID5 or RAID6 for metadata, the write hole won't affect the filesystem structure and there shouldn't be any issues for btrfs-check to find.

Re: Btrfs Coming to Fedora 33

#85

Post by Uberphallus »

nix23 wrote: post #71
Uberphallus wrote: post #52

Earlier quoted context omitted.

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.

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

The thread was about where CoW is problematic, both ZFS and Btrfs are identically problematic in this sense.

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

Like... for what we were talking about.

Re: Btrfs Coming to Fedora 33

#86

Post by prussian »

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…

honestly, I've only ever needed to rebalance on a desktop system when statfs() returned an f_bavail=0 and some program decided to take this information seriously and refused to write at all. There are still quirks with statfs info coming from btrfs volumes only solved with intense rebalancing.

Re: Btrfs Coming to Fedora 33

#87

Post by vetinari »

rwmj wrote: post #46
rkangel wrote: post #39

Earlier quoted context omitted.

Can you elaborate on the reasons for using Fedora server instead? I use Fedora Workstation on several laptops and desktops (without issue). I'm curious if I'm missing some problem/opportunity.

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.)

I'm pretty sure Fedora Workstation comes with firewalld enabled:

    $ systemctl status firewalld
    ● firewalld.service - firewalld - dynamic firewall daemon
         Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)

Re: Btrfs Coming to Fedora 33

#88

Post by LanternLight83 »

ansible wrote: post #79
codys wrote: post #76

Earlier quoted context omitted.

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.

Free space and the space taken up by metadata and snapshots can take a little attention to figure out

https://ohthehugemanatee.org/blog/2019/02/11/btrfs-out-of-sp...

Re: Btrfs Coming to Fedora 33

#89

Post by emidln »

prussian wrote: post #81
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…

I can't speak for everyone, but in terms of administration, it's much easier to deal with than having to sort through the filesystem sundae you end up making with device mapper frameworks and the filesystem cherry on top of it all. In a humorous twist, subvolumes are basically thin provisioned logical volumes too and btrfs still had quotas to make them behave as such.

I use the `lv`, `pv`, and `e2fsprogs` families of commands pretty routinely in my day job (we minimally logical volume filesystems on hosts and leave it up to application/deployment/user what to do with the bulk of the storage) and haven't found this to be a real issue. After a couple minutes thinking about what you're doing, you never really need to revisit this. You should probably spend a few minutes thinking about what you're going to be doing when dealing with your filesystems anyway.

Re: Btrfs Coming to Fedora 33

#90

Post by LanternLight83 »

symlinkk wrote: post #73
filmor wrote: post #64

Earlier quoted context omitted.

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

Is that stable?

Alright, so, disclaimer, I have lost data doing this but it was purely operator error! Closed my SSH session at the worst possible time. One of the podcast hosts at Linux Unplugged made the same mistake.

The btrfs-convert tool hypothetically leaves the ext filesystem all but untouched, and COW's the needed filesystem metadata onto the end of it, with data modifications coming thereafter (or intelligently stored within the free space of the ext system). You wait until you feel comfortable with BTRFS, then delete the preserved ext system and run a balance, which rewrites all data to disk in the usual structure. Alternatively, the preserved system can be restored, although I don't actually see instructions for that.

https://btrfs.wiki.kernel.org/index.php/Conversion_from_Ext3

I love btrfs and would trust it but am glad to have backups of irreplaceable data.

Post reply on HN