|
| ▲ | Sesse__ 33 minutes ago | parent | next [-] |
| Good thing all disks these days have data checksums, then! (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.) |
|
| ▲ | aktau 3 hours ago | parent | prev | next [-] |
| I tried btrfs on three different occasions. Three times it managed to corrupt itself. I'll admit I was too enthousiastic the first time, trying it less than a year after it appeared in major distros. But the latter two are unforgiveable (I had to reinstall my mom's laptop). I've been using ZFS for my NAS-like thing since then. It's been rock solid (). (): I know about the block cloning bug, and the encryption bug. Luckily I avoided those (I don't tend to enable new features like block cloning, and I didn't have an encrypted dataset at the time). Still, all in all it's been really good in comparison to btrfs. |
|
| ▲ | egorfine 3 hours ago | parent | prev | next [-] |
| > 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. |
| |
| ▲ | ThatPlayer 3 hours ago | parent [-] | | Bcachefs also fulfills the requirement of checksums (and multi device support). Also out of tree. | | |
| ▲ | Neikius an hour ago | parent | next [-] | | 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. | | |
| ▲ | ThatPlayer a few seconds ago | parent [-] | | I don't disagree. 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 data loss, just a pain to get the data into a new file system. |
| |
| ▲ | phoronixrly 3 hours ago | parent | prev [-] | | Does it not also eat data though? |
|
|
|
| ▲ | 3 hours ago | parent | prev | next [-] |
| [deleted] |
|
| ▲ | phoronixrly 3 hours ago | parent | prev | next [-] |
| lvm offers lvmraid, integrity, and snapshots as one example. It's old unsexy tech, but losing data is not to my taste lately... |
| |
| ▲ | fpoling an hour ago | parent [-] | | 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. | | |
|
|
| ▲ | stinkbeetle 2 hours ago | parent | prev | next [-] |
| What devices are you talking about, what's the UBER, over what period of time? RAID and logical block redundancy has scaled to petabytes for years in serious production use, before btrfs was even developed. |
|
| ▲ | Joel_Mckay 3 hours ago | parent | prev [-] |
| Could try ZFS or CephFS... even if several host roles are in VM containers (45Drives has a product setup that way.) The btrfs solution has a mixed history, and had a lot of the same issues DRBD could get. They are great until some hardware/kernel-mod eventually goes sideways, and then the auto-heal cluster filesystems start to make a lot more sense. Note, with cluster based complete-file copy/repair object features the damage is localized to single files at worst, and folks don't have to wait 3 days to bring up the cluster on a crash. Best of luck, =3 |
