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

61–70 of 140 posts

Re: Btrfs Coming to Fedora 33

#61

Post by nix23 »

wizeman wrote: post #57
nix23 wrote: post #19

Earlier quoted context omitted.

>databases, VMs, etc You should disable CoW and Caching on the filesystem/-set where VM and Databases-files reside, but that counts for ZFS as well...well for all CoW-FS's in fact.

I don't think CoW can be disabled on ZFS... which is fine because VMs and databases pretty well with ZFS, even with CoW (a block size adjustment might be needed, though).

Yes true, but with Databases you should change the recordsize to 8 or 16k (Mysql or Postgres) and tune full_page_writes in postgres to off (zfs takes care of that), and just cache the metadata because the postgres-cache is better informed of what to cache.

Re: Btrfs Coming to Fedora 33

#62

Post by nix23 »

pezezin wrote: post #54
nix23 wrote: post #19

Earlier quoted context omitted.

>databases, VMs, etc You should disable CoW and Caching on the filesystem/-set where VM and Databases-files reside, but that counts for ZFS as well...well for all CoW-FS's in fact.

I understand disabling CoW for databases, as the DB itself will manage it, but why disable caching?

In case of Postgres it knows better what to cache, you can let zfs additionally cache but it's a bit of waste, better give that ram to postgres than to Arc.

Re: Btrfs Coming to Fedora 33

#63

Post by boredishBoi »

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.

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

Re: Btrfs Coming to Fedora 33

#64

Post by filmor »

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.

Re: Btrfs Coming to Fedora 33

#65

Post by flas9sd »

> The switch to Btrfs will use a single-partition disk layout, and Btrfs’ built-in volume management. The previous default layout placed constraints on disk usage that can be a difficult adjustment for novice users. Btrfs solves this problem by avoiding it.

good call, subvolumes came to the rescue of the /home partitioning. It's useful, but the inflexibility was in the proper split of available disk space. Novice users then saw warnings for /home - when there was still plenty of space on the root partition.

Re: Btrfs Coming to Fedora 33

#66

Post by diffeomorphism »

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.

These points seem to be about why fedora workstation is not a great fit for him/her. Workstation defaults to gnome, other spins or server don't.

Re: Btrfs Coming to Fedora 33

#67

Post by 8fingerlouie »

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…

> For that you need to run btrfs-check, and that can only be done offline.

You almost never want to run btrfs-check. In itself, Btrfs is fairly "self healing", and only if you run into "weird things" in the log like invalid index files should you run check, and almost certainly never with the --repair option.

The thing about Btrfs (and ZFS) is that it is Copy-on-Write, and as such, new data is written to an unused part of the filesystem. It doesn't need to modify structures of existing data, thereby reducing the risk of bad metadata.

A file in Btrfs is either written or it is not. If a power outage occurs after a file has been written, but before the metadata is updated, the file is not written, and in case you're updating a file, the old file is still preserved.

If a crash occurs while writing metadata, Btrfs has multiple copies of metadata, and is able to repair itself online.

Re: Btrfs Coming to Fedora 33

#68

Post by diffeomorphism »

DiabloD3 wrote: post #53
vetinari wrote: post #27

Earlier quoted context omitted.

Don't worry, zfs has it's own share of problems. I have one CentOS machine where I can't update ZFS from 0.7 to 0.8, if I want to boot again (zfs#8885).

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.

Re: Btrfs Coming to Fedora 33

#69

Post by JustFinishedBSG »

nix23 wrote: post #19
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…

>databases, VMs, etc You should disable CoW and Caching on the filesystem/-set where VM and Databases-files reside, but that counts for ZFS as well...well for all CoW-FS's in fact.

No, with ZFS you just tune the recordsize of the dataset to match your database record size.

Re: Btrfs Coming to Fedora 33

#70

Post by eptcyka »

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…

I suffered a similar breakdown with no raid. But this was about 5 years ago. The filesystem filled up, had plenty of snapshots, but removing snapshots did not actually clean up any space. Had this happen twice. So I don't think this is related to RAID. Just regular old butter filesystem.

On a slightly unrelated note, I once suffered a complete failure of BTRFS where after a shutdown it just wouldn't mount anything again. Interestingly, on IRC, I was told that his is because the firmware on my Samsung NVME SSD was buggy. It might be, but ext4 has not failed me once in that regard.

Post reply on HN