All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Christoph Hellwig <hch@lst.de>
Cc: clm@fb.com, josef@toxicpanda.com, dsterba@suse.com,
	linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs: repair all bad mirrors
Date: Wed, 22 Jun 2022 13:14:30 +0800	[thread overview]
Message-ID: <baeb9e98-fba4-8af9-9fd5-da6e1bd8ee34@gmx.com> (raw)
In-Reply-To: <20220622050658.GA22104@lst.de>



On 2022/6/22 13:06, Christoph Hellwig wrote:
> On Wed, Jun 22, 2022 at 12:32:16PM +0800, Qu Wenruo wrote:
>> Personally speaking, why not only repair the initial failed mirror?
>
> Because that is a risk to data integity?  If we know there are multiple
> failures  we know that we are at risk of losing the data entirely if one
> (or in the case of raid1c4 two) additional copis fail.  And we can trivially
> fix it up.

OK, this makes sense.

>
>> It would be much simpler, no need to record which mirrors failed.
>
> How would it be "much simpler"?  You could replace the do{  } while loop
> with single call to repair_io_failure and loose the prev_mirror helper.
>
> We need to record at least one failed mirror to be able to repair it, and
> with the design in this patch we can trivially walk back from the first
> good mirror to the first bad one.

Then in that case, I guess we can also just submit the good copy to all
mirrors instead, no matter if it's corrupted or not?

But considering repair_io_failure() is still synchronous submission,
it's definitely going to be slower for RAID1C3/C4.

So the patch looks good to me now.

Just a small nitpick related to the failrec.
Isn't the whole failrec facility going to be removed after the read
repair code rework?

So I guess this patch itself is just to solve the test case failure, but
will still be replaced by the new read repair rework?

Thanks,
Qu

  reply	other threads:[~2022-06-22  5:15 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-19  8:28 [PATCH] btrfs: repair all bad mirrors Christoph Hellwig
2022-06-21 15:19 ` Nikolay Borisov
2022-06-21 15:46   ` Christoph Hellwig
2022-06-21 17:49     ` Nikolay Borisov
2022-06-22  4:23       ` Christoph Hellwig
2022-06-22  4:32 ` Qu Wenruo
2022-06-22  5:06   ` Christoph Hellwig
2022-06-22  5:14     ` Qu Wenruo [this message]
2022-06-22  7:47       ` Christoph Hellwig
2022-06-22  8:46         ` Qu Wenruo
2022-06-22 11:02           ` Christoph Hellwig

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=baeb9e98-fba4-8af9-9fd5-da6e1bd8ee34@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=hch@lst.de \
    --cc=josef@toxicpanda.com \
    --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.