3 ms·
Okay, I still don't understand your point. BTRFS stores duplicate copies of the metadata. Good for BTRFS. I don't understand how this would have prevented wh
by mustache_kimono 5y ago
Okay, I still don't understand your point.
BTRFS stores duplicate copies of the metadata. Good for BTRFS. I don't understand how this would have prevented what LTT experienced.
First, as someone else said -- no one would use a BTRFS raid5/6 array in production. No one. Second, I don't think what LTT experienced was bit rot. There were far, far too many data errors for that be simple bit rot. My guess is bad cable, bad HBA which maybe doesn't support something like ASPM, etc. Third, are we even sure the problem was corrupted metadata? Fourth, ZFS keeps redundant copies of metadata too (as do many filesystems.)
So the question is what's your point?
- namibj 5y agoThat you could have dialed up the redundancy for metadata to 3x or even 4x copies being stored, and just because a block got bitrot doesn't mean other blocks fail to read. I know no one would use Btrfs raid5/6 in production, but that's because no one wanted to enough to get the required development done. If it was just file blocks that got corrupted, there would be just very minor damage in total and a scrub that logs all damaged blocks typically proceeds at sequential read speeds from what I've observed in the past.
- chungy 5y agoZFS already stores three logical copies of all metadata, regardless of copies parameter or vdev redundancy. The failures LTT experienced went way beyond what ZFS, or btrfs, could repair. They made severe errors in judgment when setting up the system and failing to monitor and administer it. No system will ever protect against this. Not ZFS. Not btrfs.
- InvaderFizz 5y agoPlenty of people do, like my predecessors at a former job. I then had to clean up the blast from multiple BTRFS RAID6 arrays. Oh, you meant no one with a shred of responsibility, which I agree with.