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

51–60 of 140 posts

Re: Btrfs Coming to Fedora 33

#51

Post by ghaff »

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…

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

Re: Btrfs Coming to Fedora 33

#52

Post by Uberphallus »

ghaff wrote: post #51
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…

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.

Re: Btrfs Coming to Fedora 33

#53

Post by DiabloD3 »

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

Or switch distros.

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

Re: Btrfs Coming to Fedora 33

#54

Post by pezezin »

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.

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

Re: Btrfs Coming to Fedora 33

#56

Post by ansible »

ibotty wrote: post #6
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…

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-transaction taking up an increasing percentage of CPU time. Removing files and snapshots did not see an increase in free space.

So what is super-curious is that the other server, which only ever got up to about 30% full, also started exhibiting the same symptoms: unresponsive, high load from btrfs-transaction.

I was able to mount the filesystems in read-only mode, and recover the files, and checked it against the offsite backup. So no data loss, only a service loss.

Both systems had 10 or so subvolumes, and read-only snapshots were taken three times per day for each subvolume. After 4 years, that's close to 15000 snapshots, maybe more.

I searched around, but didn't find anything particularly relevant to this issue.

Re: Btrfs Coming to Fedora 33

#57

Post by wizeman »

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.

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

Re: Btrfs Coming to Fedora 33

#58

Post by ansible »

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 that you need to run btrfs-check, and that can only be done offline.

Re: Btrfs Coming to Fedora 33

#59

Post by zorked »

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…

Historically programs are "rewritten" (really, adapted) all the time to support changes to the underlying system. E.g., read-ahead, mmap() support, fadvise() support, file locking, different file locking semantics and failure modes in network filesystems, sparse files, hashed directory entries, asynchronous I/O, changes to underlying media characteristics like SSD seek times, etc.

Re: Btrfs Coming to Fedora 33

#60

Post by Uberphallus »

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?

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

Post reply on HN