Is btrfs still super slow at deleting large files? It can take multiple seconds (like 5-10) on my fileserver to delete just one ~10GB file.
Do you have snapshots enabled by any chance, or any other btrfs features?
Btrfs Coming to Fedora 33
41–50 of 140 posts
Re: Btrfs Coming to Fedora 33
#42For 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…
> is more prone to data corruption.
I'd challenge that. The main reason for using btrfs in desktop use is precisely is that your data is less likely to be corrupted. Specifically because unlike lvm+ext4, btrfs does full data checksums and therefore is capable of detecting silent data corruption.
Re: Btrfs Coming to Fedora 33
#43btrfs 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…
I'm reading through the links, and at first I thought this was a historical problem that was last reported in 2016/2017, but then gems like this from mid 2020 are popping up: "When 'btrfs scrub' is used for a raid5 array, it still runs a thread for each disk, but each thread reads data blocks from all disks in order to compute parity. This is a performance disaster, as every disk is read and written competitively by…
> BTRFS was developed largely concurrent with, and in direct competition to Sun's ZFS
ZFS started development in 2001, and released on Solaris 10 in 2006. Btrfs started development in 2007, and the disk format was stabilized in 2013. ZFS has continued to gain features over the years, but I would say btrfs was largely developed after ZFS and still hasn't reached feature parity with the original release of ZFS due to the RAID5 issue.
Re: Btrfs Coming to Fedora 33
#44Earlier 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.
Can you explain the reasoning for this?
On a copy-on-write filesystem, modification of part of a file means fragmenting it, which carries a large performance penalty. Disabling the CoW behavior means you either cannot take snapshots of the file, or that snapshots need to duplicate the file in its entirety, but it allows for quick modification of the file in-place without fragmenting.
Re: Btrfs Coming to Fedora 33
#45Earlier quoted context omitted.
I'm reading through the links, and at first I thought this was a historical problem that was last reported in 2016/2017, but then gems like this from mid 2020 are popping up: "When 'btrfs scrub' is used for a raid5 array, it still runs a thread for each disk, but each thread reads data blocks from all disks in order to compute parity. This is a performance disaster, as every disk is read and written competitively by…
> How was this never tested? You're describing this like it's supposed to work. Btrfs-raid5 is clearly labelled as a bad idea in pretty much every relevant doc. It's not an issue that the tool is broken for this use case because you're not expected to actually try that configuration. mkfs.btrfs specifically says: "RAID5/6 is still considered experimental and shouldn’t be employed for production use." It's really not…
Probably yes, but i think the comment was also about why was it implemented that way in the first place, questioning the ability and quality of the corresponding developers or how it was possible to be introduced into the filesystem code, when everybody seems to know that this is horribly broken.
Personally, i would understand if some developers tried a new approach on this raid5/6 and possibly come up with new and better solutions. I am wondering why it seems to be available in mainline. Why wasn't the patch/fork/branch rejected or why wasn't the option disabled or the code completely removed? I don't have btrfs installed but it sounds like this option is available in every btrfs release, although it is warned about to NOT USE IT. Why is it available in the first place?!
Re: Btrfs Coming to Fedora 33
#46A few points: - No this doesn't affect RHEL. - It's only for Fedora Desktop spin (which for various reasons including this, but also others, you shouldn't use even on a Desktop - I install Fedora Server on my laptop). - Only a subset of btrfs features will be used, especially avoiding the ones which are known to be problematic.
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.)
Re: Btrfs Coming to Fedora 33
#47For 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…
> is more prone to data corruption. I'd challenge that. The main reason for using btrfs in desktop use is precisely is that your data is less likely to be corrupted. Specifically because unlike lvm+ext4, btrfs does full data checksums and therefore is capable of detecting silent data corruption.
It depends what type of corruption is more likely - silent bit flips in hardware, or a bug in btrfs code.
Re: Btrfs Coming to Fedora 33
#48Earlier 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.)
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.
Re: Btrfs Coming to Fedora 33
#49I'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 without alterations being necessary, so what make Btrfs worthy of extra considerations?
At most perhaps copy-on-write (COW) file systems as a general class could perhaps be considered, as that may help with things like shingled drives and SSDs (i.e., zoned drives may be aligned with COW FSes).
Re: Btrfs Coming to Fedora 33
#50For 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…
When I replaced the SSD in my laptop with a larger one and needed to resize the partition (and filesystem, etc.) to use the capacity of the larger SSD, I had to do that at least on the filesystem, LVM and partition table levels. Or at least I don't think I found any tools that would have done the entire job for me, because I remember doing the layers step-by-step.
If there's no LVM, most point-and-click tools allow for resizing a partition and a contained filesystem in a fairly simple process. (Having a LUKS encrypted volume might complicate that, but if the encryption is on the filesystem level, that could also be avoided.)
People who dual-boot might also need to resize their partitions if their needs regarding the operating systems change, or if they made a mistake in their original allocations.
That's probably not enough of a reason to make a major switch, but it could be one task that could be simplified.