31–40 of 140 posts
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…
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…
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…
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 that big of an issue in that context. "How was running with scissors never tested for safety?" - just don't try it in the first place.
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).
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…
Subvolumes: "Lightweight partitions" allow you more easily to define the scope of a snapshot. With ext4+lvm you have to create a new partition and logical volume.
I don't think, it is a big game-changer, but then I don't think, the other things are such dealbreakers as many people think. I consider "is more prone to data corruption" as largely historical/anecdotal.
Btrfs send sounds appealing, but personally, I prefer my backup solution to be independent of the filesystem.
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…
Earlier quoted context omitted.
Synology has solved it by running btrfs on top of mdraid, then patching it so that btrfs reports errors to mdraid and putting repair code into mdraid. This reliably works. I'm sure some would be interested in this, but Synology seems to not take GPLv2 too seriously and nobody seems to care about this. RAID 5/6 in btrfs is relatively neglected because the big users that pay developers to work on btrfs (and put the wor…
They use it for everything except MySQL databases, which are stored on XFS. There was a recent discussion on LKML where Chris Mason (I think) described all this.
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…
A 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.
I use Fedora Workstation on several laptops and desktops (without issue). I'm curious if I'm missing some problem/opportunity.
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.