On 2016-11-29 07:03, Qu Wenruo wrote: [...] >> Btrfs is subject to the write hole problem on disk, but any read or >> scrub that needs to reconstruct from parity that is corrupt results in >> a checksum error and EIO. So corruption is not passed up to user >> space. Recent versions of md/mdadm support a write journal to avoid >> the write hole problem on disk in case of a crash. > > That's interesting. > > So I think it's less worthy to support RAID56 in btrfs, especially > considering the stability. > > My widest dream is, btrfs calls device mapper to build a micro RAID1/5/6/10 > device for each chunk. > Which should save us tons of codes and bugs. > > And for better recovery, enhance device mapper to provide interface to judge > which block is correct. > > Although that's just dream anyway.
IIRC in the past this was discussed, although I am not able to find any reference... BR G.Baroncelli -- gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
