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

91–100 of 140 posts

Re: Btrfs Coming to Fedora 33

#91

Post by jwatzman »

throw0101a wrote: post #49
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…

> So it's basically a matter of fixing various software to work nicely with btrfs as well as any similar filesystem. I do wonder why it isn't more supported by upstream software (postgres, VM things, etc). The concept of an application 'supporting a (specific) file system' sounds slightly ridiculous to me. Why is Btrfs so special that apps should be rewritten for it? The always-compared ZFS seems to work just fine wi…

> The concept of an application 'supporting a (specific) file system' sounds slightly ridiculous to me.

This concept is actually way less ridiculous than you might think, for any application which needs any guarantees about data durability, locking, etc (which includes everything from the obvious ones like postgres to things like Dropbox). I found https://danluu.com/deconstruct-files/ a fascinating read diving into this.

Re: Btrfs Coming to Fedora 33

#92

Post by ansible »

LanternLight83 wrote: post #88
ansible wrote: post #79

Earlier quoted context omitted.

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

Now that is interesting.

If I could mount the failed btrfs filesystem read-write for an appreciable length of time, I could try the balance operation.

I'll need to set up a cron job on the other systems to run balance on a regular basis alongside scrub (obviously not at the exact same time).

Re: Btrfs Coming to Fedora 33

#93

Post by blaser-waffle »

cpuguy83 wrote: post #80
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.

As a full-time RHEL admin, there is a reason: we have some old, like ooooooooold, kernels and servers floating around.

I can't see needing BTFS on my granddaddy boxes, but we've definitely made use of backported code.

Re: Btrfs Coming to Fedora 33

#94

Post by blaser-waffle »

eptcyka wrote: post #72
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.

That won't make them less evil, just less coherent.

Re: Btrfs Coming to Fedora 33

#95

Post by sizeofchar »

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…

Time to resilver a failed disk on btrfs depends on the amount of data on the partition, while the same on lvm is constant on the full size of the disk.

Re: Btrfs Coming to Fedora 33

#96

Post by rwmj »

vetinari wrote: post #87
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.)

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)

But with all the high ports open by default: https://lists.fedoraproject.org/archives/list/devel@lists.fe... The justification was that blocking firewall ports breaks user applications.

Re: Btrfs Coming to Fedora 33

#97

Post by tikhonj »

throw0101a wrote: post #49
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…

> So it's basically a matter of fixing various software to work nicely with btrfs as well as any similar filesystem. I do wonder why it isn't more supported by upstream software (postgres, VM things, etc). The concept of an application 'supporting a (specific) file system' sounds slightly ridiculous to me. Why is Btrfs so special that apps should be rewritten for it? The always-compared ZFS seems to work just fine wi…

To me, it doesn't sound any more ridiculous that applications having specialized support on different architectures. Most applications get away without it, but when performance really matters and general-purpose abstractions aren't sufficient, having special cases seems okay—especially when there's only a small number of architectures (or filesystems) to handle.

This can go too far—I still remember web development a decade ago—and I would prefer to have perfect abstractions that never need piercing, but absent that specialized logic seems _fine_.

Re: Btrfs Coming to Fedora 33

#99

Post by chasil »

Uberphallus wrote: post #60
pezezin wrote: post #54

Earlier quoted context omitted.

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

Depends on the RDBMS, but for big ones it's common practice to tune[0] them to allocate a big chunk of memory (or all of it) and let them manage caching by themselves. After all, they know better about the structure of the db files than the OS. [0] https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Serv... Relevant parameters: effective_cache_size/shared_buffers/work_mem

Oracle offers a document for running their database on ZFS.

https://www.oracle.com/technetwork/server-storage/solaris10/...

"The number one rule for setting up an Oracle database on ZFS is to set ZFS recordsize equal to the database block size for the file systems that contain the Oracle data files."

"Starting with Oracle Solaris 11.1, blocks that are referenced from either the snapshot or from the database image actually share ZFS cache buffers for a reduced memory footprint."

"Taking a snapshot of a database can involve placing the database in hot-backup mode just for the instant necessary to capture the ZFS snapshot. The database can then be returned to normal operation."

"A clone is a full read/write accessible fork of the original database. Therefore, by using either the primary or a replicated storage system, you can cheaply create hundreds of copies of your up-to-date database to run test and development workloads under real data conditions."

They also allow compression of the archived (intent) logs.

Re: Btrfs Coming to Fedora 33

#100

Post by vetinari »

rwmj wrote: post #96
vetinari wrote: post #87

Earlier quoted context omitted.

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)

But with all the high ports open by default: https://lists.fedoraproject.org/archives/list/devel@lists.fe... The justification was that blocking firewall ports breaks user applications.

I have mixed feelings on this:

- on one hand, nothing listens on these ports by default; and they have a point that it does break user applications;

- on the other hand, they should be closed, and users should open them explicitly once they install an app that needs it. However, I'm afraid we would see exactly the same thing we see with SELinux: many tutorials about installing apps or services start with "Disable SELinux" instead of how to enable exactly what is needed. We would see the same thing with firewall and "Disable firewall" as step 1.

- as a sidenote to the second point: many apps do not ship with firewalld profile, so it is not a matter of `firewall-cmd -add-service $appname` either.

Post reply on HN