31–40 of 73 posts
> Case study: recovery of a severely corrupted 12 TB multi-device pool, plus constructive gap analysis and reference tool set #1107 Please don't be btrfs please don't be btrfs please don't be btrfs...
Earlier quoted context omitted.
What are the alternatives to btrfs? At 12 TB data checksums are a must unless the data tolerate bit-rot. And if one wants to stick with the official kernel without out-of-tree modules, btrfs is the only choice.
lvm offers lvmraid, integrity, and snapshots as one example. It's old unsexy tech, but losing data is not to my taste lately...
> Case study: recovery of a severely corrupted 12 TB multi-device pool, plus constructive gap analysis and reference tool set #1107 Please don't be btrfs please don't be btrfs please don't be btrfs...
Where are all of the ZFS corruption stories? Or are there simply fewer of those?
And on btrfs anything above raid1 (5,6 etc) has had very serious bugs. Actually read an opinion somewhere (don't remember where) raid5,6 on btrfs cannot work due to on-disk format being just bad for the case. I guess this is why raid1c3/c4 is being promoted and worked on now?
Earlier quoted context omitted.
> if one wants to stick with the official kernel without out-of-tree modules I wonder how could a requirement like that possibly arise. Especially with an obvious exception for zfs.
Bcachefs also fulfills the requirement of checksums (and multi device support). Also out of tree.
Earlier quoted context omitted.
lvm offers lvmraid, integrity, and snapshots as one example. It's old unsexy tech, but losing data is not to my taste lately...
lvm only supports checksums for metadata. It does not checksum the data itself. For checksums with arbitrary filesystems one can have dm-integrity device rather than LVM. But the performance suffer due to separated journal writes by the device.
To theal author: did you continue using btrfs after this ordeal? An FS that will not eat (all) your data upon a hard powercycle only at the cost of 14 custom C tools is a hard pass from me no matter how many distros try to push it down my throat as 'production-ready'... Also, impressive work!
What are the alternatives to btrfs? At 12 TB data checksums are a must unless the data tolerate bit-rot. And if one wants to stick with the official kernel without out-of-tree modules, btrfs is the only choice.
(50TB+ on ext4 and xfs, and no, no bit rot. Yes, I've checked most of it against separate sha256sum files now and then. As long as you have ECC RAM, disks just magically corrupting your data is largely a myth.)
> This is not a bug report. [...] The goal is constructive, not a complaint. Er, I appreciate trying to be constructive, but in what possible situation is it not a bug that a power cycle can lose the pool? And if it's not technically a "bug" because BTRFS officially specifies that it can fail like that, why is that not in big bold text at the start of any docs on it? 'Cuz that's kind of a big deal for users to know.…
btrfs's reputation is not great in this regard.
Earlier quoted context omitted.
Bcachefs also fulfills the requirement of checksums (and multi device support). Also out of tree.
Isn't bcachefs even younger and less polished than btrfs? It does show more promise as btrfs seems to have fundamental design issues... but still I wouldn't use that for my important data.
Just talking about filesystems with checksumming (and multidevice). Any new filesystem to support these features is going to be newer.
I've had both btrfs and bcachefs multidevice filesystems lock up read-only on me. So no real data loss, just a pain to get the data into a new file system, the time it was an 8 drive array on btrfs.
> Case study: recovery of a severely corrupted 12 TB multi-device pool, plus constructive gap analysis and reference tool set #1107 Please don't be btrfs please don't be btrfs please don't be btrfs...
Where are all of the ZFS corruption stories? Or are there simply fewer of those?