Тут реддитом настолько прекрасное принесло, что просто оставлю это здесь, в назидание и чтоб больше не искать:https://lore.kernel.org/linux-btrfs/20200520013255.GD10769.../
Первую половину этой писанины можно смело пропустить и перейти к "рекомендациям" (я пропустил объяснения причин):
2.6 to 3.4: don't use btrfs on these kernels
3.5 to 3.8: don't use raid5 or raid6
3.9 to 3.18: don't use raid5 or raid6
3.19 to 4.4: don't use raid5 or raid6
4.5 to 4.15: don't use raid5 or raid6
4.16 to 5.0: use raid5 data + raid1 metadata. Use only
with space_cache=v2. Don't use raid6
5.1: don't use btrfs on this kernel
5.2 to 5.3: don't use btrfs on these kernels
5.4: use raid5 data + raid1 metadata. Use only with
space_cache=v2. Don't use raid6
Don't use kernels 5.4.0 to 5.4.13 with btrfs
5.5 to 5.7: use raid5 data + raid1 metadata, or raid6 data raid1c3 metadata. Use only with space_cache=v2.
On current kernels there are still some leftover issues:
- btrfs sometimes corrupts parity if there is corrupted data [skip]
- there is some risk of data loss due to write hole [skip]
И вот это самое прекрасное:
- scrub can detect parity corruption but [skip] (i.e. error counts will be distributed randomly across all disks). This cannot be fixed with the current on-disk format.
То есть "мы обнаруживаем повреждение данных, но показываем его не на том диске, где на самом деле, и чинить, разумеется, не будем".
Never use raid5 or raid6 for metadata because the write hole and parity corruption bugs still present in current kernels will race to see which gets to destroy the filesystem first.
По-моему автор мог бы быть более краток - newer use btrfs (because...20 страниц перечня родовых травм "which cannot be fixed with the current on-disk format"). И неважно, по какой причине какую версию.