On stable hardware, Btrfs raid56 should be stable. As the code everywhere is constantly changing I guess it's somewhat subjective if raid56 specific changes mea

On stable hardware, Btrfs raid56 should be stable. As the code everywhere is constantly changing I guess it's somewhat subjective if raid56 specific changes mean the code is not stable. Some seemingly small changes 4.17 to 4.18 thus far. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/fs/btrfs/raid56.c?id=v4.18-rc3&id2=v4.17 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... And bigger changes from 4.14 to 4.17. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/fs/btrfs/raid56.c?id=v4.17&id2=v4.14 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... I don't have a complete or detailed breakdown, but I think a big chunk of Btrfs raid56 problems would have affected any raid56 implementation, including the crazy Linux 30s command timeout default. Many I've seen are single drive failures, with an additional bad sector on another drive. If Btrfs itself detects an error (csum mismatch for metadata or data) on a remaining drive, this is no different than a two "device" failure for that stripe. More reliable than raid5 for metadata and data, is to use raid1 metadata and raid5 data (this can be chosen at mkfs time or you can do a balance with -mconvert=raid1 to convert raid5 metadata to raid1). And for all raid, it's questionable if raid56 is a good idea with 5+TB drives taking days to rebuild.