All of lore.kernel.org
 help / color / mirror / Atom feed
From: Goffredo Baroncelli <kreijack@libero.it>
To: Jarkko Lavinen <jlavi@iki.fi>, linux-btrfs@vger.kernel.org
Subject: Re: [BUG] Btrfs scrub sometime recalculate wrong parity in raid5
Date: Mon, 18 Jul 2016 20:56:22 +0200	[thread overview]
Message-ID: <cc93fc7e-2bbf-40c3-807e-2b7d0b962335@libero.it> (raw)
In-Reply-To: <20160716155111.GA9751@ks392938.kimsufi.com>

Hi

On 2016-07-16 17:51, Jarkko Lavinen wrote:
> On 07/12/2016 05:50 PM, Goffredo Baroncelli wrote:
>> Using "btrfs insp phy" I developed a script to trigger the bug.
> 
> Thank you for the script and all for sharing the raid5 and scrubbing
> issues. I have been using two raid5 arrays and ran scrub occasionally
> without any problems lately and been in false confidence. I converted
> successfully raid5 arrays into raid10 without any glitch.
> 
> I tried to modify the shell script so that instead of corrupting data
> with dd, a simulated bad block is created with device mapper. Modern
> disks are likely to either return the correct data or an error if
> they cannot.


You are right; but doing so we are complicating further the test case:
- my tests show what happen when there is a corruption, but the drive behaves well
- your tests show what happen when there is a corruption AND the drive has a failure

I agree that your simulation is more realistic, but I fear that doing so we are complicating the bug finding.

> 
> The modified script behaves very much like the original dd version.
> With dd version I see wrong data instead of expected data. 

When toy say "I see wrong data", you means with 
1) "cat mnt/out.txt" 
or 2) with "dd if=/dev/loop....." ?

In the first case I see always good data; in the second case I see wrong data but of course no reading error

> With simulated bad block I see no data at all instead of expected data
> since dd quits on read error.
> 
> Jarkko Lavinen
> 


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5



  parent reply	other threads:[~2016-07-18 18:56 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-12 21:50 [BUG] Btrfs scrub sometime recalculate wrong parity in raid5: take two Goffredo Baroncelli
2016-07-14 21:20 ` Chris Mason
2016-07-15  4:39   ` Andrei Borzenkov
2016-07-15 13:20     ` Chris Mason
2016-07-15 15:10       ` Andrei Borzenkov
2016-07-15 15:21         ` Chris Mason
2016-07-15 16:30     ` Goffredo Baroncelli
2016-07-15 16:28   ` Goffredo Baroncelli
2016-07-15 16:29     ` Chris Mason
2016-07-15 16:34       ` Andrei Borzenkov
2016-07-16 15:51 ` [BUG] Btrfs scrub sometime recalculate wrong parity in raid5 Jarkko Lavinen
2016-07-17 19:46   ` Jarkko Lavinen
2016-07-18 18:56   ` Goffredo Baroncelli [this message]
  -- strict thread matches above, loose matches on Subject: below --
2016-08-19 13:17 Philip Espunkt
2016-06-25 12:21 Goffredo Baroncelli
2016-06-25 17:25 ` Chris Murphy
2016-06-25 17:58   ` Chris Murphy
2016-06-25 18:42     ` Goffredo Baroncelli
2016-06-25 22:33       ` Chris Murphy
2016-06-26  9:20         ` Goffredo Baroncelli
2016-06-26 16:43           ` Chris Murphy
2016-06-26  2:53   ` Duncan
2016-06-26 22:33     ` ronnie sahlberg
2016-06-26 22:38       ` Hugo Mills
2016-06-27  3:22         ` Steven Haigh
2016-06-27  3:21       ` Steven Haigh
2016-06-27 19:47         ` Duncan
2016-06-27  3:50       ` Christoph Anton Mitterer
2016-06-27  4:35         ` Andrei Borzenkov
2016-06-27 16:39           ` Christoph Anton Mitterer
2016-09-21  7:28 ` Qu Wenruo
2016-09-21  7:35   ` Tomasz Torcz
2016-09-21  9:15     ` Qu Wenruo
2016-09-21 15:13       ` Chris Murphy
2016-09-22  2:08         ` Qu Wenruo
2016-09-22  2:44           ` Chris Murphy
2016-09-22  3:00             ` Qu Wenruo
2016-09-22  3:12               ` Chris Murphy
2016-09-22  3:07           ` Christoph Anton Mitterer
2016-09-22  3:18             ` Qu Wenruo
2016-09-21 15:02   ` Chris Murphy
2016-11-04  2:10 ` Qu Wenruo
2016-11-05  7:23   ` Goffredo Baroncelli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cc93fc7e-2bbf-40c3-807e-2b7d0b962335@libero.it \
    --to=kreijack@libero.it \
    --cc=jlavi@iki.fi \
    --cc=kreijack@inwind.it \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.