How about fixing RAID5 first please? At least for non-metadata blocks ("-draid5 -mraid1" or "-draid6 -mraid1c3")? https://phoronix.com/scan.php?page=news_item

How about fixing RAID5 first please? At least for non-metadata blocks ("-draid5 -mraid1" or "-draid6 -mraid1c3")? https://phoronix.com/scan.php?page=news_item&px=Btrfs-Warning-RAID5-RAID6 https://phoronix.com/scan.php?page=news_item&px=Btrfs-Warnin... It's kind of insane that two companies now sell a fixed btrfs-RAID5 as a proprietary commercial product (yes, in spite of the GPL). They do it by using the mdadm RAID5 code, which works, and add proprietary hooks to allow btrfs to use its checksums to figure out which spindle is corrupt in a parity mismatch situation. This (a) closes the write hole without a journal doubling the I/O load and (b) detects silent corruption, neither of which mdadm can do. Or just upstream this patch set: https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg93181.html https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg... ...so we can do this ourselves with LVM (split each spindle into a small metadata device and a large device, stitch the large data devices together with mdadm-raid5/6, then add that and all the small devices to a btrfs filesystem with the small devices marked "metadata only" and -dsingle -mraid1c3). I really feel like the btrfs guys are stuck in "shiny new thing" mode here. Last time I checked host-managed SMR devices were only available in engineering sample quantities. Even if that's changed they surely are still very rare, a tiny minority of worldwide storage device sales. The fact that btrfs-RAID5 scrubs take something like O(num_spindles^2) seek latencies is crazy... I have an 8-spindle array that scrubs in 12 hours with "-draid0" but takes 10 days with "-draid5".