From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f47.google.com ([209.85.218.47]:33006 "EHLO mail-oi0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751650AbcFXRGN (ORCPT ); Fri, 24 Jun 2016 13:06:13 -0400 Received: by mail-oi0-f47.google.com with SMTP id u201so123448536oie.0 for ; Fri, 24 Jun 2016 10:06:12 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <20160620204049.GA1986@hungrycats.org> <20160621015559.GM15597@hungrycats.org> <20160622203504.GQ15597@hungrycats.org> <5790aea9-0976-1742-7d1b-79dbe44008c3@inwind.it> <20160624014752.GB14667@hungrycats.org> <576CB0DA.6030409@gmail.com> <20160624085014.GH3325@carfax.org.uk> From: Chris Murphy Date: Fri, 24 Jun 2016 11:06:09 -0600 Message-ID: Subject: Re: Adventures in btrfs raid5 disk recovery To: Andrei Borzenkov Cc: Hugo Mills , Zygo Blaxell , Chris Murphy , kreijack@inwind.it, Roman Mamedov , Btrfs BTRFS Content-Type: text/plain; charset=UTF-8 Sender: linux-btrfs-owner@vger.kernel.org List-ID: On Fri, Jun 24, 2016 at 3:52 AM, Andrei Borzenkov wrote: > On Fri, Jun 24, 2016 at 11:50 AM, Hugo Mills 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. -- Chris Murphy