On Tue, Aug 30, 2016 at 3:32 AM, Richard Brown
All RAID 5/6 implementations, including hardware ones, are at risk of a 'write hole', when something interupts the write. When this happens, the parity information doesn't match the rest of the data for the stripe.
mdadm now has a journal to avoid this problem. https://lwn.net/Articles/665299/ As for Btrfs, this has been asked a few times on the list, but those familiar enough with raid56 haven't replied. If full stripe writes are always CoW, and the stripe doesn't really "exit" until it's completely committed both in metadata as well as super block, then how does the write hole happen? If it happens, it suggests partial writes aren't CoW. And that has implications for csum consistency also, not just parity. OK so let's say partial stripe writes are overwrites, not CoW. When Btrfs runs into a bad data strip, either by drive read error or by data csum mismatch, Btrfs reconstructs the data from parity. It does this blindly because parity strips themselves are not checksummed. Upon reconstruction, it compares to data csum, and if there's a mismatch it reports an I/O error in kernel messages as well as up to user space. So does the write hole exist on Btrfs? If we agree to split the problem into two parts: the inconsistency between data and parity strips vs silent data corruption ensuing from reconstruction from bad parity: Btrfs does have the former problem, it does not have the latter. -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org