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

121–130 of 140 posts

Re: Btrfs Coming to Fedora 33

#121

Post by pseudalopex »

chasil wrote: post #78
viraptor wrote: post #28

Earlier quoted context omitted.

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

The first link actually explains why ZFS is no more dangerous than any other filesystem.

Re: Btrfs Coming to Fedora 33

#122

Post by tinus_hn »

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.

Clearly you weren’t around in the days when NFS was a thing.

Re: Btrfs Coming to Fedora 33

#123

Post by eptcyka »

cmurf wrote: post #111
eptcyka wrote: post #70

Earlier quoted context omitted.

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 ag…

With SSD it's common that they start returning zeros or garbage, sometimes transiently, before they fail. In the case of single device Btrfs, it basically acts as an early warning detection system, and it will be a lot more sensitive to this than other file systems because both metadata (the fs itself) and your data, are checksummed. And the data is a much bigger portion of the payload on your drive. It's way more li…

That SSD seemed healthy in every other respect and it's still chugging along today just fine. On ZFS no less. The kicker in the catastrophic failure was that none of the recovery tools worked and I'd need to write my own recovery tools to fill in the gaps where the metadata got corrupted. I also did not have much time to faff about - I imaged the disk and reinstalled the machine. As for the metadata, I was under the impression that there were no checksums for metadata in BTRFS?

Re: Btrfs Coming to Fedora 33

#124

Post by auxym »

tinus_hn wrote: post #122
throw0101a wrote: post #49

Earlier quoted context omitted.

> 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. Clearly you weren’t around in the days when NFS was a thing.

Wait, NFS isn't a thing anymore?

Re: Btrfs Coming to Fedora 33

#125

Post by WGH_ »

cmurf wrote: post #115
knorker wrote: post #105

Earlier quoted context omitted.

I'm talking about the time it takes for the `rm` command to finish. I've started the habit of running all `rm` commands in the background on btrfs.

If it's reproducible, my suggestion is to strace the rm command and find out what it's doing that's taking so long; and post it to the mailing list: https://btrfs.wiki.kernel.org/index.php/Btrfs_mailing_list

Recording the kernel profile with perf would be more useful, I think. strace would probably only show long "unlink" syscall.

Re: Btrfs Coming to Fedora 33

#126

Post by _-david-_ »

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?

I think RHEL currently uses XFS and Fedora uses ext4 so they are already not using the same file system. Its possible Fedora will switch to btrfs and RHEL will remain on XFS.

Re: Btrfs Coming to Fedora 33

#127

Post by throw0101a »

tinus_hn wrote: post #122
throw0101a wrote: post #49

Earlier quoted context omitted.

> 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. Clearly you weren’t around in the days when NFS was a thing.

> Clearly you weren’t around in the days when NFS was a thing.

I was and am. I currently help admin an HPC environment with several petabytes of NFS storage.

And the main problems I've experienced with NFS have generally been with Linux locking. I've had a lot less drama with Solaris and BSD NFS (though I did uncover two Solaris NFS server bugs over the years).

Whenever I have NFS issues I generally start with the assumption that there's a bug in the NFS client code.

Re: Btrfs Coming to Fedora 33

#128

Post by throw0101a »

vetinari wrote: post #27
znpy wrote: post #3

I just herd my roommate saying "i don't want to play too much with my amd cpu overclocking because if i crash my system too much btrfs might get corrputed again". laughs in zfs

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

* https://github.com/openzfs/zfs/issues/8885

This seems to be more of a udev and 'device' discovery problem than something inherit to ZFS/ZoL.

Re: Btrfs Coming to Fedora 33

#129

Post by tinus_hn »

throw0101a wrote: post #127
tinus_hn wrote: post #122

Earlier quoted context omitted.

> The concept of an application 'supporting a (specific) file system' sounds slightly ridiculous to me. Clearly you weren’t around in the days when NFS was a thing.

> Clearly you weren’t around in the days when NFS was a thing. I was and am. I currently help admin an HPC environment with several petabytes of NFS storage. And the main problems I've experienced with NFS have generally been with Linux locking. I've had a lot less drama with Solaris and BSD NFS (though I did uncover two Solaris NFS server bugs over the years). Whenever I have NFS issues I generally start with the as…

If you think applications work on NFS by just expecting general Unix filesystem semantics you’re in for a surprise.

The fact you’re not having trouble just means either the application writers put in the effort to properly support it, or your use case is simple enough not to run into problems.

Re: Btrfs Coming to Fedora 33

#130

Post by cmurf »

eptcyka wrote: post #123
cmurf wrote: post #111

Earlier quoted context omitted.

With SSD it's common that they start returning zeros or garbage, sometimes transiently, before they fail. In the case of single device Btrfs, it basically acts as an early warning detection system, and it will be a lot more sensitive to this than other file systems because both metadata (the fs itself) and your data, are checksummed. And the data is a much bigger portion of the payload on your drive. It's way more li…

That SSD seemed healthy in every other respect and it's still chugging along today just fine. On ZFS no less. The kicker in the catastrophic failure was that none of the recovery tools worked and I'd need to write my own recovery tools to fill in the gaps where the metadata got corrupted. I also did not have much time to faff about - I imaged the disk and reinstalled the machine. As for the metadata, I was under the…

Superblocks, and every node and leaf in every tree is checksummed. While it's possible to disable checksumming and copy-on-write for data, it's not possible for metadata (the fs itself).
Post reply on HN