24.06.2016 20:06, Chris Murphy пишет: > On Fri, Jun 24, 2016 at 3:52 AM, Andrei Borzenkov <arvidj...@gmail.com> wrote: >> On Fri, Jun 24, 2016 at 11:50 AM, Hugo Mills <h...@carfax.org.uk> wrote: >> eta)data and RAID56 parity is not data. >>> >>> Checksums are not parity, correct. However, every data block >>> (including, I think, the parity) is checksummed and put into the csum >>> tree. This allows the FS to determine where damage has occurred, >>> rather thansimply detecting that it has occurred (which would be the >>> case if the parity doesn't match the data, or if the two copies of a >>> RAID-1 array don't match). >>> >> >> Yes, that is what I wrote below. But that means that RAID5 with one >> degraded disk won't be able to reconstruct data on this degraded disk >> because reconstructed extent content won't match checksum. Which kinda >> makes RAID5 pointless. > > I don't understand this. Whether the failed disk means a stripe is > missing a data strip or parity strip, if any other strip is damaged of > course the reconstruction isn't going to match checksum. This does not > make raid5 pointless. >
Yes, you are right. We have double failure here. Still, in current situation we apparently may end with btrfs reconstructing missing block using wrong information. As was mentioned elsewhere, btrfs does not verify checksum of reconstructed block, meaning data corruption. -- 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
